Skip to content
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

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

BenjamenMeyer
Copy link
Member

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

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:

  • What is this pull request trying to do? Breaking down the code structure into smaller, independent components
  • What release is this for? 0.10.x
  • Is there a project or milestone we should apply this to? 0.10.x

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
Copy link
Contributor

@royfalk royfalk left a 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
Copy link
Contributor

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. 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.
  2. 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

Copy link
Member Author

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)
Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Contributor

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.

@BenjamenMeyer
Copy link
Member Author

NOTE: I reviewed the build failures:

  • The Mac build failed due to not finding the endian.h system header included by our endianness.h header
  • The Windows builds failed due to not finding expat.h

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.

Copy link
Contributor

@royfalk royfalk left a 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
Copy link
Contributor

@vincele vincele Mar 9, 2025

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

Copy link
Member Author

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.

Move the dependency detection to the root so it can span the
libraries.

Rename `TST_LIBS` and `TST_INCLUDES` in the engine to have a VSE_
prefix so that it doesn't mess up other libraries.
@BenjamenMeyer
Copy link
Member Author

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.

Initialize the TST_INCLUDES and TST_LIBS variables for CMake
Add TST_INCLUDES to the include list for CMake
@BenjamenMeyer
Copy link
Member Author

BenjamenMeyer commented Mar 10, 2025

@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.

@BenjamenMeyer
Copy link
Member Author

NOTE: for some reason MacOS wasn't falling into the BSD/FreeBSD logic for the Endianness header... added a __APPLE__ case too.

@BenjamenMeyer
Copy link
Member Author

welll....traded up one Mac error (endian.h) for another (boost/move/utility_core.hpp)...neither really makes sense for why they're happening in this PR in particular when they not in others.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants