Replies: 1 comment 6 replies
-
Is there any particular reason why you went for a sub module? When you check out a project with submodules you have to do an extra step in order to get them, which is why I think there's a lot of negativity around git sub modules. Have you taken a look at https://github.com/jrouwe/JoltPhysicsHelloWorld? This is by far the easiest way of including a 3rd party module in your own cmake project and it is very hassle free for your end users as it automatically downloads Jolt in the background. |
Beta Was this translation helpful? Give feedback.
6 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I'm learning how to include this in my 3D engine and settled on making it a git submodule, but I want everyone who builds my engine to not get caught up in the specifics of building Jolt. Ideally I run my engine's CMakeLists.txt and Jolt gets compiled automatically.
Maybe my CMakeLists.txt should auto-select the script in
JoltPhysics/Build/
? Or should people manually build Jolt themselves using one of those, and rely on my CMakeLists.txt linking Jolt viafind_library()
oradd_library("Jolt.lib" STATIC)
? I like the idea of Jolt sharing the same Visual Studio solution as my code if it's going to be a static lib.I also want all the special vector instructions and interprocedural optimization off for some build configurations but if I change that in my local Jolt repo then git says the submodule has uncommitted changes, which makes me think I need my own CMakeLists.txt for Jolt.
Thanks for any help, I'm not the build engineer type and am new to physics engines.
Beta Was this translation helpful? Give feedback.
All reactions