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

Re-Structure cmake solution to be closer to the scons solution. #1595

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

enetheru
Copy link
Contributor

This is just a single step, re-arranging the code without actually changing its functionality.

new docs/cmake.md
moved the block of comments from the start of the CMakeLists.txt into the cmake.md file and converted content to markdown.

new cmake/godotcpp.cmake
Moved all exposed options into a new function godotcpp_options() Moved configuration and generation code into godotcpp_generate()

To get all the options into the godotcpp_options() I changed the logic of GODOT_USE_HOT_RELOAD which I believe is a closer match to scons, that if the options is not set, and the build type is not release, then it defaults to ON.

@enetheru
Copy link
Contributor Author

I guess I have to go install msvc now.

@enetheru
Copy link
Contributor Author

I did end up being able to replicate the issue locally by copying the commands from the CI logs, and it turns out to be a fairly obscure issue. These links describe the problem, and current solutions. I did not see any information on a better way.
https://discourse.cmake.org/t/how-do-i-remove-compile-options-from-target/5965
https://stackoverflow.com/questions/74426638/how-to-remove-rtc1-from-specific-target-or-file-in-cmake

@enetheru enetheru marked this pull request as ready for review September 18, 2024 21:46
@enetheru enetheru requested a review from a team as a code owner September 18, 2024 21:46
@enetheru
Copy link
Contributor Author

This pull request purposefully tries to make no changes to the code, since it would be hidden by the re-structure.
There is only one real change to the logic, and thats to how the USE_HOT_RELOAD flags is set, and checked. Which I believe brings it inline with the SCons more closely.
The rest is simply re-arrangement

@enetheru enetheru force-pushed the restructure branch 2 times, most recently from b197d23 to 355e16a Compare September 18, 2024 22:41
@enetheru
Copy link
Contributor Author

Last update I swear, I just wanted to be really responsible with the build tree.

@dsnopek dsnopek added cmake topic:buildsystem Related to the buildsystem or CI setup labels Sep 19, 2024
@dsnopek dsnopek added this to the 4.x milestone Sep 19, 2024
@enetheru
Copy link
Contributor Author

I want provide more evidence as to how these changes effect (or in this case dont effect) the build.

If you perform a diff of the CI build logs minus the timestamps, you get essentially the same exact log with some slight( and i mean very slight) variability between compile order.

Build times for MSVC as I couldnt see duration times in the other runners and I didnt want to manually check the log timestamps:

  • godot-cpp: 00:14:56.81
  • godot-cpp-test: 00:00:13.45

Other CI build times:
PR#2272
Time Elapsed 00:14:49.99
Time Elapsed 00:00:11.95

PR#2271
Time Elapsed 00:55:12.92
Time Elapsed 00:00:18.67

PR#2270
Time Elapsed 00:15:01.23
Time Elapsed 00:00:13.30

PR#2265
Time Elapsed 00:14:25.67
Time Elapsed 00:00:11.69

@enetheru
Copy link
Contributor Author

There is also this to consider: cmake/GodotCompilerWarnings.cmake → cmake/common_compiler_flags.cmake
I didn't think this would be a problem, but in true form, if its visible people will use it. Testing with Orchestrator on my other patch showed that it was being included in a downstream project. Such a thing isnt necessary after the modernise PR as transient flags are specified explicitly.

This is just a single step, re-arranging the code without actually changing its functionality.

new docs/cmake.md
moved the block of comments from the start of the CMakeLists.txt into the cmake.md file and converted content to markdown.

new cmake/godotcpp.cmake
Moved all exposed options into a new function godotcpp_options()
Moved configuration and generation code into godotcpp_generate()

To get all the options into the godotcpp_options() I changed the logic of GODOT_USE_HOT_RELOAD which I believe is a closer match to scons, that if the options is not set, and the build type is not release, then it defaults to ON.

I msvc builds require the default flags to be modified or it will throw errors. I have added the links to articles in the commit, but its about removing the runtime error checks /RTC1 from the CMAKE_CXX_FLAGS_DEBUG variable. This needs to happen before the files are included.
https://stackoverflow.com/questions/74426638/how-to-remove-rtc1-from-specific-target-or-file-in-cmake
https://discourse.cmake.org/t/how-do-i-remove-compile-options-from-target/5965

Renamed GodotCompilerWarnings.cmake to common_compiler_flags.cmake to match scons

Included files explicitly by path, as we dont need to append to the CMAKE_MODULES_PATH which effects the whole build tree.

This prevents consumers of the library from clobbering the names of the cmake include files and breaking the build.
Copy link
Member

@aaronfranke aaronfranke left a comment

Choose a reason for hiding this comment

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

This is an excellent first step! While I'm not an expert in CMake, this looks good and works in testing.

Copy link
Collaborator

@dsnopek dsnopek left a comment

Choose a reason for hiding this comment

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

Thanks!

Overall, this looks good to me! I tried to go through the old and new line-by-line, and this does seems mostly like a straight re-organization. Moving us closer to the organization of the scons config is a great idea, because it'll make it easier for contributors to add new features in both places.

I just have the couple notes I put on the docs (together with the issue when attempting to use a separate build directory).

Comment on lines +26 to +27
cmake .
cmake --build .
Copy link
Collaborator

Choose a reason for hiding this comment

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

Do we really want to recommend running cmake . at the top-level like this? My understanding is that cmake folks tend to prefer making a build directory like:

mkdir build
cd build
cmake ..

Also, we have a Makefile at the top-level in the Git repo, so on Linux if you run cmake ., it ends up replacing the Makefile.

So, if we do decide to recommend running cmake like this, we should probably consider removing that Makefile?

Copy link
Member

Choose a reason for hiding this comment

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

I agree, considering the mess CMake makes it's best to recommend using a subfolder. I commented here that we should pick a specific subfolder name such as cmake_build, put it in the gitignore, and use it in all documentation and CI stuff. #1598 (comment)

Generate the buildfiles in a sub directory to not clutter the root directory with build files:

```shell
mkdir build && cd build && cmake -G "Unix Makefiles" .. && cmake --build .
Copy link
Collaborator

Choose a reason for hiding this comment

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

Ah, I see you have it down here!

Unfortunately, this doesn't seem to work? When I run it, it still generates the Makefile at the top-level, it doesn't put it in the build/ directory - it even says so in its output:

$ cmake -G "Unix Makefiles" ..
-- Configuring done
-- Generating done
-- Build files have been written to: /home/dsnopek/prj/default/godot-cpp

@enetheru
Copy link
Contributor Author

enetheru commented Sep 28, 2024 via email

Copy link
Collaborator

@dsnopek dsnopek left a comment

Choose a reason for hiding this comment

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

I agree, however it is out of scope for this PR. Which is to rearrange what
exists with minimal changes.

Yeah, that makes sense: if those things are broken even before this PR, then we don't need to fix them here.

We should address those things soon, though, because we're documenting a process that is problematic, and another process that seems not to work. If that can be included in PR #1598, that would be really great

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

Successfully merging this pull request may close these issues.

3 participants