-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Just wanted to provide some update on this change.
* %__cmake_in_source_build macro has been introduced and set to 1. It
controls what arguments are passed to `cmake -B ...`, `cmake --build
...`, `cmake --install ...` and in which directory `ctest` is executed.
If it is set to anything, it will use `.` as a directory so that build
is done in-place.
* %cmake now always passes -S/-B options.
* %cmake_build/%cmake_install/%ctest macros have been created.
* %cmake_kf5 changes are in progress by Neal at this moment.
So far these changes are not breaking (it becomes breaking if you unset
`%__cmake_in_source_build` macro), so we plan to backport them in
stable Fedora releases so that spec files can stay compatible across
Fedora branches.
I've ran scratch rebuilds of ~2k packages that are affected (not
including %cmake_kf5 changes yet). Only ~900 succeeeded (definitely
will be lower once we get %cmake_kf5 changes are in). The ones that
failed are:
* 141 use `cd builddir; cmake ..; make` pattern
* 823 use `cmake; make` pattern
* 96 failed for irrelevant or overlooked problem
Once %cmake_kf5 changes are ready, I'll start new mass-scratch-rebuild-
of-affected-packages.
NOW: I've booked 4 hours session this Sunday with Neal to go and fix
broken packages. If you are interested to help - let me know and I'll
send you an invitation.
Will keep you updated :)
On Mon, 2020-06-15 at 15:47 -0400, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
== Summary ==
<code>%cmake</code> macro will be adjusted (<code>-B</code>
parameter)
to use separate build folder (already standardized
<code>%{_vpath_builddir}</code> macro). Additionally,
<code>%cmake_build</code>, <code>%cmake_install</code> and
<code>%ctest</code> macro will be created (and backported to the
older
supported Fedora releases) 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.
== Owner ==
* Name: [[User:ignatenkobrain|Igor Raits]], [[User:besser82|Björn
Esser]], [[User:ngompa|Neal Gompa]]
* Email: ignatenkobrain(a)fedoraproject.org,
besser82(a)fedoraproject.org,
ngompa13(a)gmail.com
== Detailed Description ==
Historically, software builds had a singular build configuration and
required running the build within the project root. Nowadays, there
are many build modes and options that can be configured in projects,
different build settings (e.g. compiler flags) / types (release,
debug) that can be applied and different tools that can be used to
actually execute builds (compilers like gcc/clang, build job
schedulers like make/ninja, and so on). Thus, CMake upstream strongly
discourages users of doing in-source builds and recommends doing
out-of-source builds.
From <code>cmake.1</code>:
<pre>
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.
</pre>
The other part of the change is introduction of additional macros is
creation of set of macro that can build, install and run tests in a
backend-agnostic, vpath-aware (out-of-source, in-source) way.
=== Migration ===
==== <code>%cmake</code> +
<code>%(make|ninja)_(build|install)</code>
====
There are multiple paths to complete the migration:
* Add <code>-C "%{_vpath_builddir}"</code> to the
<code>%(make|ninja)_*</code>
* Replace <code>%(make|ninja)_build</code> and
<code>%(make|ninja)_install</code> with <code>%cmake_build</code>
and
<code>%cmake_install</code> respectively
* Redefine vpath builddir <code>%global _vpath_builddir .</code> to
continue performing in-source builds (and optionally converting to
the
<code>%cmake_*</code>)
Depending on the package, one of these options may be used to adapt
to
this change.
==== <code>%cmake -B builddir</code> +
<code>%(make|ninja)_(build|install) -C builddir</code> ====
No changes are needed.
== Benefit to Fedora ==
* Follow CMake upstream recommendations when building packages
* Brings Fedora package builds more in-line with how upstream
projects
expect them to be built
* Improve compatibility with other RPM distributions that already do
this
* Support backend-agnostic way of building CMake projects
== Scope ==
* Proposal owners: Implement necessary macros, try to build packages
that <code>BuildRequires: cmake</code> in a side tag, 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: [
https://pagure.io/releng/issue/9524 #9524]
* Policies and guidelines: CMake page will 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 as many Fedora packages as possible. However
fixing third-party packages is not possible and out of scope.
Third-party packagers will need to adapt based on the recommendations
noted in this Change.
== How To Test ==
# Grab the new cmake RPM from the Koji sidetag (TBC)
# Try to build package that uses <code>%cmake</code>,
<code>%cmake_build</code>, <code>%cmake_install</code> and
<code>%ctest</code> macro
== User Experience ==
The end-users (non-packagers) will not notice any changes.
== Dependencies ==
There are around 1100 RPMs in Fedora that depend on CMake at
build-time. 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
== Documentation ==
The only place that needs to be adjusted is packaging guidelines.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to
devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedora...
- --
Igor Raits <ignatenkobrain(a)fedoraproject.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7/bdQACgkQEV1auJxc
Hh6gqA/+Ikcoe9Qbros85W+XwrvWWS1kFlm7jopthDSLIIP2w9QlViEc+fpW58bu
aDCECCRnZDhJrI1olYE/J+14yrqNql4WkSvg0EfcgDmasayZsWTR4TBW3OD9mwdK
YVFj461dx9/Xvro5ygsJl8HYCcj/cxhzCVYK6DfwFWL7/T5I1apEozNKm7/Nso0D
04Lv7I2/QPEGzHoLA2nrAOGbc8QiNIWecFiRAGJKa/p3k3rhrcfq6KXZXdU8YQzZ
rvYUJyippEk+GMbN6IEJA73v+wQYLDbVUpgeRD1k7zh5QqiBsTHZWDi0yhq5a0O/
A8bHmFBfQYAr+yWByIdX1php38hjMBWatq9SuCV0tzNtXhievaiVYA1UaMjY7zR2
vucWYtYbrtYcQWvB/yImk15Ju3Y7PB4Cl9lpXvLZgwpVs79m5zHksQlQR2Flld/H
349LnDCB+0dTruvNVegm+R7jeSHA+Nsq5xknq2JJcw8Pj+h/2CHtNTh3eGcKDx3y
pKrofNcDgp5rVAOfZPpaw9xPyQFZeL+h2cMcwL9Vy/folB6U89dPMPRogtd3q44B
MEE3GmpPBFGn+LywWcs7X1d1VNPdoJGsa5fbDo/g2uTOXTbhnrq7TUHcRIphM1TK
eHO/k4hJN6HVvZ8Iha7l/IQh8bomYaHhVQdCRua7XNgq3N67G+4=
=VNBj
-----END PGP SIGNATURE-----