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

Tidy the cmake config and add better build configuration support. #226

Merged
merged 2 commits into from Aug 12, 2021

Conversation

dbaarda
Copy link
Member

@dbaarda dbaarda commented Aug 10, 2021

This is an idea taken from the following post;

https://blog.kitware.com/cmake-and-the-default-build-type/

It sets the default build type to Debug for git clone, otherwise the default is Release. It also sets possible values for the cmake-gui or ccmake. It works with multi-config generators and respects values set on the cmdline.

This is an idea taken from the following post;

https://blog.kitware.com/cmake-and-the-default-build-type/

It sets the default build type to Debug for git clone, otherwise the default
is Release. It also sets possible values for the cmake-gui or ccmake. It works
with multi-config generators and respects values set on the cmdline.
@dbaarda
Copy link
Member Author

dbaarda commented Aug 12, 2021

I have some mild concerns about this related to the following comment;

https://blog.kitware.com/cmake-and-the-default-build-type/#comment-8726

I don't know who might be affected by this though. Surely distro's relying on building using the default empty build-type have a workaround for projects using this approach.

I feel like the benefits of using this outweigh the risks. It means most naive users doing their own builds will end up with a Debug build with trace turned on, improving the chance they will detect problems. The improved cmake-gui and ccmake build-type selection will also make it easier for them to select a Release build when they realize they've been using a Debug build. Outputting the build-type in a cmake message makes it easier for them to realize/verify what build-type they are using.

Advanced users will already be setting CMAKE_BUILD_TYPE on the cmake cmdline, and this will not affect them.

I did try experimenting with supporting a build type of "" in the selection options but it doesn't work. The empty option disappears from the selection list, and setting -DCMAKE_BUILD_TYPE="" is the same as not setting it at all from the point of view of detecting/setting the default to Debug. It is possible but a bit ugly to add a "empty" build type that can be selected on the cmdline and saved in the cmake cache that then clears CMAKE_BUILD_TYPE, but it's a bit ugly.

So I think I'm going to submit this and we'll address any problems later if they surface.

@dbaarda dbaarda merged commit 3fca937 into librsync:master Aug 12, 2021
@dbaarda dbaarda deleted the dev/cmake1 branch August 12, 2021 03:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant