CMake to do out-of-source builds
Summary
%cmake macro will be adjusted (-B parameter) to use separate build folder (already standardized %{_vpath_builddir} macro). Additionally, %cmake_build, %cmake_install and %ctest macro will be created to perform various operations that are commonly used with CMake in a backend-agnostic (Makefiles, Ninja, etc.) way.
Packages that will stop building are trivial to fix and will be adjusted either by maintainers or change owners.
For the older supported Fedora releases, the non-breaking macros will be backported.
Owner
- Name: Igor Raits, Björn Esser, Neal Gompa
- Email: ignatenkobrain@fedoraproject.org, besser82@fedoraproject.org, ngompa13@gmail.com
Current status
- Targeted release: Fedora 33
- Last updated: 2020-06-13
- FESCo issue: <will be assigned by the Wrangler>
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
Detailed Description
Historically, buildsystems were doing in-source builds and one configuration. Nowadays, there are tons of options that can be configured in projects, different build settings (e.g. compiler flags) / types (release, debug) that can be applied and different tooling that is going to actually build sources (compilers, buildsystems like make / ninja). Thus CMake upstream is discouraging users to build in-source and recommends doing out-of-source builds.
From the cmake.1:
To maintain a pristine source tree, perform an out-of-source build by using a separate dedicated build tree. An in-source build in which the build tree is placed in the same directory as the source tree is also supported, but discouraged.
The other part of the change is introduction of additional macros
Feedback
Benefit to Fedora
- Follow CMake upstream recommendations when building packages
- Improve compatibility with other RPM distributions
- Support backend-agnostic way of building CMake projects
Scope
- Proposal owners: Implement necessary macro, try to build packages in a side tag (that have BuildRequires: cmake), analyze failures and fix the relevant ones (introduced by this change).
- Other developers: While proposal owners will try to fix all affected packages, there might be some cases where package is already FTBFS so the fix can't be performed. Other package maintainers will have to fix the issue themselves after they fix FTBFS.
- Release engineering: #9524
- Policies and guidelines: CMake page should be adjusted to mention newly created macros and the documentation about relevant VPATH macros needs to be restructured a bit (they are already documented on the Meson page, they need to be moved to the separate page and referenced both from CMake and Meson page).
- Trademark approval: N/A (not needed for this Change)
Upgrade/compatibility impact
Existing packages can (and most likely will) become FTBFS, but proposal owners will fix most (as much as they can) of the Fedora packages. However fixing of 3rd party packages is not possible and out of scope.
How To Test
1. Grab the new cmake RPM from the Koji sidetag (TBC)
2. Try to build package that uses %cmake, %cmake_build, %cmake_install and %ctest macro
User Experience
The end-users (non-packagers) will not notice any changes.
Dependencies
There are around 1100 RPMs in Fedora that BuildRequire CMake. All proposal owners are provenpackagers so they are able to commit necessary fixes. No external dependencies.
Contingency Plan
- Contingency mechanism: Proposal owners will adjust macros to not do out-of-source builds by default, but will preserve newly created macro (essentially to bring them to the targeted state of older supported Fedora releases).
- Contingency deadline: Beta freeze.
- Blocks release? No
- Blocks product? product
Documentation
The only place that needs to be adjusted is packaging guidelines.