-
-
Notifications
You must be signed in to change notification settings - Fork 593
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
Modernise existing cmake options #1598
Conversation
Looks like I have to fix up the test case |
Because of the changes, the CI stopped working, so I needed to overhaul the test/CMakeLists.txt to consider the changes, and reduced the cmake code dramatically. |
461fa63
to
c51489b
Compare
Again to aid with verification, here is a google doc spreadsheet showing the differences in output. If there's anything you'd like me to check please mention it. |
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.
Overall the organization in this PR looks great. There's a lot missing still but as you stated that is expected for this first PR. I like how it lays out a plan for what's to come. When we get to implementing features such as architecture handling in a future PR I have a branch here, which enetheru already knows about, just linking for easy access.
I tried testing this PR. I was able to build godot-cpp by itself, but I was not able to get the test project to build. I tried running cmake --build . --verbose -j $(nproc) -t godot-cpp-test
(copied from the CI script in this PR) on macOS and it fails silently, no compiled files showed up in the bin folder. Although I wasn't able to get the test project working on master either, with a lot of errors being printed on master.
I also tried compiling Godot Orchestrator with this PR, which is a big Godot project using CMake. I had to make two expected changes to Orchestrator to make it compile: replacing INCLUDE(GodotCompilerWarnings)
with INCLUDE(common_compiler_flags)
(it's fine to have to make changes, since we don't guarantee API stability with the CMake files) and changing the Godot minor version to 3 to work around an Orchestrator bug. However, it then failed to compile with the error c++: error: unsupported option '-static-libgcc'
. I've already opened a bug report for this here #1522 but it's strange that the bug didn't show up with Orchestrator with master, and doesn't show up in godot-cpp by itself either with master or this PR. Anyway, worth looking into if we can fix #1522 - AFAICT we shouldn't ask clang to be static libgcc since it's not gcc (or, if there is an obscure reason why it is needed, then there needs to be a comment, and we need to fix whatever is causing compilation to fail). However, just removing this line doesn't fix it, it will then complain about -R
being unrecognized. Anyway, if fixing #1522 is not in-scope then it can be fixed in a follow-up PR.
I found some issues with my hasty conversion of the test project. |
So it looks both like RPATH is not relevant to windows, and that clang and gcc differ in their flags to set it. since I dont currently have a linux or mac computer, perhaps @aaronfranke you might be able to get some compiler and link output for me that I can see what is listed when you compile? I think CMAKE will automatically do it using the target properties feature, but since I am currently on windows I cant tell.. I can get a linux machine up and running soon, but it might not be before I go on holiday. But I have no access to a mac. |
I'll try to see whats up with orchestrator. |
Ivan has provided me some feedback: https://gist.github.com/IvanInventor/339f686883ea184b632bad1fcd183462#gistcomment-5199373 |
After reviewing how orchestrator expected to include the headers, I made an adjustment which is in keeping with those expectations. The include path is now exported to consumers, rather than all the header files individually. |
@aaronfranke Success!, Yeah so line 115, remove the INCLUDE( GodotCompilerWarnings ) is the only change I had to make. I have orchestrator example project working on godot/4.3, godot-cpp/modernise |
My spreadsheet is updated, mainly for the msvc version, which is really annoying because I'm mostly a Linux guy. There are real problems that need to be addressed. |
I just buttoned down the last few remaining items that were on my concerns list. I think I can now justify the tiny changes, like filenames matching the build config, compile definitions, and warnings as being slightly more correct than the master branch. I'm very confident that this will improve the lives of everyone who chooses cmake, whether that is personal preference, or that their other dependencies require it. |
Pretty sure this is done.. |
@dsnopek OK, so I am back from my holiday in Europe( which was great ) and I want to get back onto this. I remember their being a request in the re-structure comments to update the docs/cmake.md with updated information. Is there anything else that is wanted from this? Regarding the documentation, I've been trying to think(granted jetlag is still an issue) about the purpose of what is there and I think it is not coherant. Building the godot-cpp static library separately to an extension using cmake is not the cmake way. I cant quite make an argument for the doc/cmake.md existence that would not have a more appropriate alternative. |
I can provide more information in that file in the way of documentation if you like? It cant hurt. I'll review the differences and see if I can't document how it works. |
If you just mean putting a comment in EDIT: Ah, I see you already added it! It looks good to me :-) |
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.
The latest version of this is looking great to me!
Thanks so much for your hard work and persistence :-)
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.
Hi, glad to see you stepping up to modernise the CMake files! A lot of people will appreciate this. It might help us with one project as well :)
I just tested your branch and got an error for the default config on macOS (x86_64, building universal (default)):
cmake .
godot-cpp modernise* ≡
❯ cmake .
Auto-detected 8 CPU cores available for build parallelism.
Using cores, You can override it at configure time by using -j <n> or --parallel <n> on the build command.
eg. cmake --build . -j 7 ...
-- Configuring done (0.3s)
-- Generating done (0.6s)
-- Build files have been written to: /Users/lukas/dev/godot/godot-cpp
godot-cpp modernise* ≡
❯ cmake --build . --verbose -t godot-cpp-test
Change Dir: '/Users/lukas/dev/godot/godot-cpp'
Run Build Command(s): /nix/store/dlk5mzpxif2hjfw43if4wid0sckv6sx7-cmake-3.29.6/bin/cmake -E env VERBOSE=1 /usr/bin/make -f Makefile godot-cpp-test
/nix/store/dlk5mzpxif2hjfw43if4wid0sckv6sx7-cmake-3.29.6/bin/cmake -P /Users/lukas/dev/godot/godot-cpp/CMakeFiles/VerifyGlobs.cmake
/nix/store/dlk5mzpxif2hjfw43if4wid0sckv6sx7-cmake-3.29.6/bin/cmake -S/Users/lukas/dev/godot/godot-cpp -B/Users/lukas/dev/godot/godot-cpp --check-build-system CMakeFiles/Makefile.cmake 0
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f CMakeFiles/Makefile2 godot-cpp-test
/nix/store/dlk5mzpxif2hjfw43if4wid0sckv6sx7-cmake-3.29.6/bin/cmake -P /Users/lukas/dev/godot/godot-cpp/CMakeFiles/VerifyGlobs.cmake
/nix/store/dlk5mzpxif2hjfw43if4wid0sckv6sx7-cmake-3.29.6/bin/cmake -S/Users/lukas/dev/godot/godot-cpp -B/Users/lukas/dev/godot/godot-cpp --check-build-system CMakeFiles/Makefile.cmake 0
/nix/store/dlk5mzpxif2hjfw43if4wid0sckv6sx7-cmake-3.29.6/bin/cmake -E cmake_progress_start /Users/lukas/dev/godot/godot-cpp/CMakeFiles 33
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f CMakeFiles/Makefile2 test/CMakeFiles/godot-cpp-test.dir/all
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f CMakeFiles/template_debug.dir/build.make CMakeFiles/template_debug.dir/depend
cd /Users/lukas/dev/godot/godot-cpp && /nix/store/dlk5mzpxif2hjfw43if4wid0sckv6sx7-cmake-3.29.6/bin/cmake -E cmake_depends "Unix Makefiles" /Users/lukas/dev/godot/godot-cpp /Users/lukas/dev/godot/godot-cpp /Users/lukas/dev/godot/godot-cpp /Users/lukas/dev/godot/godot-cpp /Users/lukas/dev/godot/godot-cpp/CMakeFiles/template_debug.dir/DependInfo.cmake "--color="
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f CMakeFiles/template_debug.dir/build.make CMakeFiles/template_debug.dir/build
[ 0%] Building CXX object CMakeFiles/template_debug.dir/src/classes/editor_plugin_registration.cpp.o
/Users/lukas/.nix-profile/bin/c++ -DDEBUG_ENABLED -DDEBUG_METHODS_ENABLED -DGDEXTENSION -DHOT_RELOAD_ENABLED -DMACOS_ENABLED -DUNIX_ENABLED -I/Users/lukas/dev/godot/godot-cpp/include -I/Users/lukas/dev/godot/godot-cpp/gen/include -I/Users/lukas/dev/godot/godot-cpp/gdextension -O3 -DNDEBUG -std=c++17 -arch x86_64 -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.1.sdk -mmacosx-version-min=14.5 -fPIC -fvisibility=hidden -fno-exceptions -fno-gnu-unique -Wall -Wctor-dtor-privacy -Wextra -Wno-unused-parameter -Wnon-virtual-dtor -Wwrite-strings -Walloc-zero -Wduplicated-branches -Wduplicated-cond -Wno-misleading-indentation -Wplacement-new=1 -Wshadow-local -Wstringop-overflow=4 -Wattribute-alias=2 -Wlogical-op -Wno-return-type -MD -MT CMakeFiles/template_debug.dir/src/classes/editor_plugin_registration.cpp.o -MF CMakeFiles/template_debug.dir/src/classes/editor_plugin_registration.cpp.o.d -o CMakeFiles/template_debug.dir/src/classes/editor_plugin_registration.cpp.o -c /Users/lukas/dev/godot/godot-cpp/src/classes/editor_plugin_registration.cpp
g++: error: this compiler does not support ‘arm64’
make[3]: *** [CMakeFiles/template_debug.dir/src/classes/editor_plugin_registration.cpp.o] Error 1
make[2]: *** [CMakeFiles/template_debug.dir/all] Error 2
make[1]: *** [test/CMakeFiles/godot-cpp-test.dir/rule] Error 2
make: *** [godot-cpp-test] Error 2
It notably works in scons; I can't run arm64 files but I can compile them no problem.
When configuring for x86_64 it seems to work:
cmake -D GODOT_ARCH=x86_64 .
godot-cpp modernise* ≡
❯ cmake -D GODOT_ARCH=x86_64 .
Auto-detected 8 CPU cores available for build parallelism.
Using cores, You can override it at configure time by using -j <n> or --parallel <n> on the build command.
eg. cmake --build . -j 7 ...
-- Configuring done (0.4s)
-- Generating done (0.6s)
-- Build files have been written to: /Users/lukas/dev/godot/godot-cpp
godot-cpp modernise* ≡
❯ cmake --build . --verbose -t godot-cpp-test
Change Dir: '/Users/lukas/dev/godot/godot-cpp'
Run Build Command(s): /nix/store/dlk5mzpxif2hjfw43if4wid0sckv6sx7-cmake-3.29.6/bin/cmake -E env VERBOSE=1 /usr/bin/make -f Makefile godot-cpp-test
/nix/store/dlk5mzpxif2hjfw43if4wid0sckv6sx7-cmake-3.29.6/bin/cmake -P /Users/lukas/dev/godot/godot-cpp/CMakeFiles/VerifyGlobs.cmake
/nix/store/dlk5mzpxif2hjfw43if4wid0sckv6sx7-cmake-3.29.6/bin/cmake -S/Users/lukas/dev/godot/godot-cpp -B/Users/lukas/dev/godot/godot-cpp --check-build-system CMakeFiles/Makefile.cmake 0
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f CMakeFiles/Makefile2 godot-cpp-test
/nix/store/dlk5mzpxif2hjfw43if4wid0sckv6sx7-cmake-3.29.6/bin/cmake -P /Users/lukas/dev/godot/godot-cpp/CMakeFiles/VerifyGlobs.cmake
/nix/store/dlk5mzpxif2hjfw43if4wid0sckv6sx7-cmake-3.29.6/bin/cmake -S/Users/lukas/dev/godot/godot-cpp -B/Users/lukas/dev/godot/godot-cpp --check-build-system CMakeFiles/Makefile.cmake 0
/nix/store/dlk5mzpxif2hjfw43if4wid0sckv6sx7-cmake-3.29.6/bin/cmake -E cmake_progress_start /Users/lukas/dev/godot/godot-cpp/CMakeFiles 33
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f CMakeFiles/Makefile2 test/CMakeFiles/godot-cpp-test.dir/all
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f CMakeFiles/template_debug.dir/build.make CMakeFiles/template_debug.dir/depend
cd /Users/lukas/dev/godot/godot-cpp && /nix/store/dlk5mzpxif2hjfw43if4wid0sckv6sx7-cmake-3.29.6/bin/cmake -E cmake_depends "Unix Makefiles" /Users/lukas/dev/godot/godot-cpp /Users/lukas/dev/godot/godot-cpp /Users/lukas/dev/godot/godot-cpp /Users/lukas/dev/godot/godot-cpp /Users/lukas/dev/godot/godot-cpp/CMakeFiles/template_debug.dir/DependInfo.cmake "--color="
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f CMakeFiles/template_debug.dir/build.make CMakeFiles/template_debug.dir/build
[ 0%] Building CXX object CMakeFiles/template_debug.dir/src/classes/editor_plugin_registration.cpp.o
...
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 looked a bit further at my previous issues. It looks like this is a g++13 issue that is resolved in later versions. The reason my cmake config is encountering this while my scons config isn't is that scons uses builtin clang while my nix cmake uses g++13:
❯ /Users/lukas/.nix-profile/bin/c++ --version
g++ (GCC) 13.3.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
godot-cpp modernise* ≡
❯ clang++ --version
Apple clang version 16.0.0 (clang-1600.0.26.4)
Target: x86_64-apple-darwin23.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
So yeah, probably not related to your PR!
That's really interesting, I will try installing gcc on my mac mini and see if it has similar detection issues. |
You may not have the same experience. I used |
yeah installing gcc through brew doesnt at all clobber the builtin compiler detection. I woud have to create a toolchain, or alter environment variables to change that. I'm thinking thta nix is sort of like how msys on windows cretes its own environment. |
- Added to .gitignore CMakeUserPresets.json ### Configuration: - Changed python command to use single quotes to make build output log more legible. - Added GODOT_DEV_BUILD to allow differentiation of debug or Release builds. - Added find logic for macos Cocoa library ### godot-cpp Changes - godot-cpp-test is changed to be incorporated into the cmake build as a target. - Duplicated godot-cpp target into [template_release, template_debug, editor] - Created {platform}.cmake files mirroring the style of the SCons build. CMake has a feature called generator expressions for its configuration variables that are evaluated at build time. This allows multi-configuration build systems to properly evaulate options. for msvc, xcode and nijna multi-config. - Moved configuration options to generator expressions with the notable exclusion of OSX_ARCHITECTURES. - Remove CMAKE_BUILD_TYPE from msvc CI target as Multi-Config generators ignore it ### godot-cpp-test Changes - Removed majority of the cmake code, now that the godot-cpp project is setup, the majority of the flags will be propagated as transient dependencies - Marked with EXCLUDE_FROM_ALL so that it isn't built as part of the 'all' target - Updated ci to build the godot-cpp-test target from the root directory using cmake - Tests passing for Windows, Linux, and Macos builds. ### Documentation Updated with new information Added Emscripten example Added Android example
Thanks! 🎉 |
OMG!!! yay, I've been sick for the last three days, this cheers me up immensely. :D |
Modernise existing cmake options
Modernise existing cmake options Merge pull request godotengine#1647 from enetheru/fix#1459 CMake: Align MSVC runtime (MD[d], MT) options to engine Merge pull request godotengine#1649 from enetheru/fix-backward-break CMake: fix break for build prior to modernisation PR
Not sure if this related but our linux gcc 13.1 ci stops collecting warnings, because of thousands of
This would suppress the warnings in theory:
Related MR |
Does this work for you? I've searched through documentation for gcc and cant find that flag. |
Ah you're right, I'm sorry. Are you getting these warnings as well, in general? This looks more and more like an issue on my end. I've had issues the last view days with cmake trying to compile godot-cpp with the default msvc version, that is cpp98, so I can see how this is maybe related that the compilation flags do not get applied or overwritten. Maybe even one of our vpckg does some compilation flag shenanigans... |
|
||
# These compiler options reflect what is in godot/SConstruct. | ||
target_compile_options( ${TARGET_NAME} | ||
PUBLIC |
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 was this changed from PRIVATE to PUBLIC? I was wondering why my code suddenly complained about std::throw. AFAIK setting this to PUBLIC also means that also all CMake targets that consume this library get these compile flags applied....
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 is because a lot of things were changed, there was no propagation at all previously, and setting it to public seemed expedient at the time to propagate some flags that were necessary, and I do not have a great mental model for what should be propagated and what should not yet.
I Was indeed hoping that someone like yourself would notify me if there was a problem and we could resolve it, thereby solving it using reality rather than some made up idealistic notion I might have.
So there's the why, what needs to change? what options can be private that dont effect consumers?
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.
@kelteseth I've been testing, I think I can make almost all the flags PRIVATE. I'll subit a PR privatising as much as I can.
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.
Nice 🚀
Modernise existing cmake options
Modernise existing cmake options Merge pull request godotengine#1647 from enetheru/fix#1459 CMake: Align MSVC runtime (MD[d], MT) options to engine Merge pull request godotengine#1649 from enetheru/fix-backward-break CMake: fix break for build prior to modernisation PR CMake: Fix selection of MSVC Runtime compile flags My last attempt at solving this was not correct. I have left lots of comments in the source detailing the issue as it will effect consumers. Replace empty EXCLUDE variable with EXCLUDE_FROM_ALL This was a mistake left over from the modernise PR CMake: Handle GODOT_DEV_BUILD flag correctly .dev is added to output artifacts Warn users for specifying dev_build and Release build config Update documentation with deviations to SCons Update debug_symbols handling, its rolled into build config Cleanup helper variables and comments CMake: Enable using clang-cl on windows detect clang with MSVC frontend using CMAKE_CXX_COMPILER_FRONTEND_VARIANT Alleviate CMake target name clashes, visibility, and grouping. Simplify <platform>_generate cmake function signature, as TARGET_ALIAS and TARGET_NAME are still in scope and do not need to be passed. Add USE_FOLDERS, and FOLDER properties to group targets in VS and XCode Guard test target with GODOT_ENABLE_TESTING Tidy Small Issues remove RPATH_USE_ORIGIN from static libs add INTERFACE_POSITION_INDEPENDENT_CODE ON reset GODOT_ARCH property to SYSTEM_ARCH for macos because universal add MACOSX_RPATH to test target remove redundant properties from test target remove redundant and PUBLIC cxx_std_17 compile feature Privatise compiler options. CMake: Support using build_profile.json Python: - Redirect stdout for get_file_list to prevent stdout pollution CMake: - add GODOT_BUILD_PROFILE cache option - Split file list generation into its own function - add status and debug messages Python Snippets in CMake: - re-format for better readability Build Profile: - Add missing VisualInstance3D class to build_profile.json Add CMake support for XML documentation Implement generate_doc_source for cmake Implement generate_doc_source for cmake CMake: add lto options add a fake target to expose results of generator expressions move location of genex debug target so that it picks up the target details properly and allows us to generate for each type. first attempt Simplify Code Generation Variables - use generator expressions - use math for bits - simplify if statements Simplify SYSTEM_NAME generator expression. previous version created a list, which is semicolon delimited and then string REPLACED the semicolon to create a single string. New version uses string APPEND to create the string the first time. Update Target Properties - Using rpath for a static library is irrelevant, needs to be seet in consumers. - Add INTERFACE_POSITION_INDEPENDENT_CODE to propogate flag to consumers. Update macos - Add TODO for missing options - Fix formatting - Set GODOT_ARCH in case of arch being 'universal' - Simplify the test project when SYSTEM_NAME is Darwin Refactor common_compiler_flags.cmake - remove incorrectly propagated target_compile_features - remove GNU_ prefix on generic compiler version genex's - remove line breaks for simple genex's - make most flags private - comments Update Comments - Add TODO items for missing options - Add missing toolchain managed options commented out - Homogenise Headings and block comments replace ad-hock name construction with new GODOT_SUFFIX - This replicates how SCons does it. - Modify test project to use GODOT_SUFFIX - Add GODOT_SUFFIX to libgodot-cpp properties set web shared lib suffix to bring web builds into line with SCons
PUBLIC | ||
-sSIDE_MODULE | ||
-sSUPPORT_LONGJMP=wasm | ||
-fno-exceptions |
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've noticed that adding -fno-exception
here is a discrepancy since the SCons build doesn't do this, as far as I know.
I would like to know what's the reason for this.
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 agree, perhaps a copy paste mistake on my part. It doesn't need to be there.
This PR builds on #1595
In this PR, I hope to consolidate all the existing code into one style so that we can start adding things that exist in the scons build but are missing from cmake that people have requested.
The primary changes are
Tests for Linux, Macos, and Windows are passing.
This style is cleaner and supports the multi-config generators like Visual Studio and Ninja-Multi-Config. Tho I find it slightly more annoying to debug personally, it is the better method.
I've been making sure these builds are Identical using this spreadsheet
Commit log