Modernize the CMake build files #102
Conversation
List of things that this commit brings: * Makes the project `FetchContent` ready This is achieved by conditionally executing code that is only useful for a consumer of the project, such as examples. * Componentize the install rules Because this is a header-only library, its install rules should be categorized in a dev component (think foo-dev packages in apt). By assigning all install rules to a component, the project no longer clobbers the global component when vendored (see the previous point). * Provide an interface similar to the install interface when vendored This is achieved by adding SYSTEM to the include directories conditionally and only providing targets that are actually needed. * Make the project architecture independant This is achieved by setting the ARCH_INDEPENDENT argument when generating the version config file, which is available since CMake 3.14. This feature is intended to be used for header-only libraries. * Misc changes for trivial packaging The install rules are written in a way that allows package maintainers to trivially package the project.
|
Hey, this is awesome, thanks!
I don't envision I'd do that for toml++ since meson is already working nicely for me, though I would consider it for a fresh project at some point. I think that'd be a better learning opportunity. There's some CMake FetchContent documentation in the toml++ README and on the main homepage; will these changes require any updates to that documentation, or will it still be OK? |
|
No, that documentation is still technically correct, although FetchContent is just vendoring code with different steps, so it is still not favorable to consume dependencies in general. Good thing about FetchContent is that one can just declare a dependency ahead of time using code injection and subsequent declare calls for the same name will be no-ops, but still not ideal.
cmake-init is there if you'd like to use it. It's a WIP at the moment, but feedback is always welcome!
Just a word of advice, but for me tackling the topic was a near full time endeavour for a couple months. Not because CMake is a bad or badly documented tool, but because of the sheer size of the domain it solves problems in, which can be chalked up to cross-platform development in general. Most of my time was really spent on looking into the intricacies of different platforms, issues that come with that and how CMake can solve those. My recent efforts went into coming up with solutions for project management, and I think having a general and on top of that a developer code path in CML files allows easy (re)usage of projects by both developers and consumers. |
2 participants
What does this change do?
FetchContentreadyThis is achieved by conditionally executing code that is only useful
for a consumer of the project, such as examples.
Because this is a header-only library, its install rules should be
categorized in a dev component (think foo-dev packages in apt). By
assigning all install rules to a component, the project no longer
clobbers the global component when vendored (see the previous point).
This is achieved by adding SYSTEM to the include directories
conditionally and only providing targets that are actually needed.
This is achieved by setting the ARCH_INDEPENDENT argument when
generating the version config file, which is available since CMake
3.14. This feature is intended to be used for header-only libraries.
The install rules are written in a way that allows package maintainers
to trivially package the project.
Additionally, if you ever wish to completely move the build tooling of this library to CMake, only minimal changes are necessary from this point on:
With a developer mode you may add testing, docs, benchmarks, whatever else your heart desires, without disturbing regular consumers who couldn't care less about those things.
With presets you can add warning flags, extra configurations for coverage, sanitizers, etc without hardcoding things into the CML files. Generally, you want to avoid putting anything in the CML files that aren't build or usage requirements. Warning flags are neither of those :)
A helpful template in the contributing guidelines with a developer mode preset can be helpful for those not yet familiar with this type of workflow and its benefits.
All of the above can be seen in action in the example repositories listed in cmake-init's readme. There is also an example for vcpkg integration that can help you to get rid of git submodules.
I have read on Reddit that you are putting off learning CMake, I hope the above link can help you to kick-start that endeavour. If you have questions, feel free to open a discussion in that repository or shoot me an email at [email protected]
Is it related to an exisiting bug report or feature request?
No.
Pre-merge checklist
origin/master(if necessary)