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(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.
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!