On Tue, Jul 7, 2020 at 1:57 PM Orion Poplawski orion@nwra.com wrote:

On 6/15/20 1:47 PM, 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@fedoraproject.org, besser82@fedoraproject.org,

ngompa13@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.

What's the plan for EPEL8/7 compatibility?

I need to talk to EPEL folks about how to handle this. I'm not sure exactly what strategy we should take here. I could override the macros entirely with epel-rpm-macros, which is probably the easiest way to do it.

-- 真実はいつも一つ！/ Always, there's only one truth!