-
-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor: move collide2 out as a library #1041
base: master
Are you sure you want to change the base?
Refactor: move collide2 out as a library #1041
Conversation
Add a new `libraries` directory in parallel to the `engine` for our various library components, and add the `collide2` code there as the first library component as it is the most independent of the various libraries. NOTE: There is no real code change outside of header includes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty straightforward. Not sure how meaningful it is without encapsulating it from the rest of the code though.
# collide2 headers | ||
${CMAKE_CURRENT_SOURCE_DIR} | ||
# VS engine headers | ||
#${CMAKE_SOURCE_DIR}/engine |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please open an issue for refactoring VS out of collide library. It's no good separating it out if it refers to VS all over.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- collide2 is generally under a difference license (public domain from what I can tell... or rather the UNLICENSE) so at a minimum we gain that clarity.
- agreed - there's a few things (gfx/quaternion.h) that seem to have gotten spread out. it'd be nice to make it more independent that way.
Filed #1042
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at the build failures (#1041 (comment)) I'll have to address some of this somehow... but my goal is to be minimal right now. Not sure if I'll fix up #1041 immediately or just move some checks around in CMake for the moment so Mac/Win builds succeed - more likely just move stuff around b/c it'll probably make more sense long term with other libraries being split out any way.
|
||
#Find Math | ||
INCLUDE(CheckSymbolExists) | ||
IF(NOT POW_FUNCTION_EXISTS AND NOT NEED_LINKING_AGAINST_LIBM) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was unable to find a lot of information about this. Is there really a chance modern systems don't have POW? (whatever that is)
I'm asking because a lot of stuff in our cmake was really legacy from 2001.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I doubt it. Created #1043 to follow up on that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need pow
. This block of code tells us where to find it (i.e., what library). I don't think this code should be removed.
NOTE: I reviewed the build failures:
Both of these were while building the the collide2 library. Interestingly, Linux has no issue with either of these. Probably means that some of the library searches we do in the VS engine need to be more universal for now - at least until #1041 can be completed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK. Make it build and run and ship it.
@@ -52,6 +53,9 @@ LIST(APPEND | |||
${CMAKE_CURRENT_SOURCE_DIR}/src/resource | |||
${CMAKE_CURRENT_SOURCE_DIR}/src/python/base_computer | |||
${CMAKE_CURRENT_SOURCE_DIR}/src/python/config | |||
# Library Headers | |||
${CMAKE_SOURCE_DIR}/libraries/collide2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just ${CMAKE_SOURCE_DIR}/libraries
? That would remove the need to modify a lot of the #include
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consistency between the libraries. Honestly I'd like to get the headers paths down to a lot more limit set long term so this is the first step along a longer path trajectory.
The library itself should use its own directory as the import path so its self-contained. Similarly the code linking against it needs to use the same path so that they can pull in the headers for a library.
In my own code I split out headers as their own thing:
project
project\include
project\src
and then external sources linking link against the project\include
. We haven't agreed to that here right now and given our state I'm not ready to push that question; we have a lot of other things that are more important; but that would also change this to:
${CMAKE_SOURCE_DIR}/libraries/collide2
That said, I'd also like to find a CMake way to do this automatically by searching for the directories under ${CMAKE_SOURCE_DIR}/libraries
and then adding them; however I haven't been able to find a directive that would allow that yet - it finds source files easily, but not directories or at least not filtered to a single level.
Moved a chunk of the dependency searching to the root; this should fix Windows. Not sure about the endian one, but need a check and see how the CI system does with this change before debugging further. Play tested a little to see how it was doing, and also brought up-to-date with master. |
@stephengtuggy I need some help figuring out the Windows side. Mac is still misbehaving but I think I can figure that out for the moment. I filed #1059 as a long term issue for what's going on with Mac but will try to get it working in the immediate here. |
NOTE: for some reason MacOS wasn't falling into the BSD/FreeBSD logic for the Endianness header... added a |
welll....traded up one Mac error ( |
Add a new
libraries
directory in parallel to theengine
for our various library components, and add thecollide2
code there as the first library component as it is the most independent of the various libraries.NOTE: There is no real code change outside of header includes
Thank you for submitting a pull request and becoming a contributor to the Vega Strike Core Engine.
Please answer the following:
Code Changes:
Issues:
Purpose: