On Mon, Jun 15, 2020 at 1:49 PM Ben Cotton <bcotton@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxx, besser82@xxxxxxxxxxxxxxxxx, > ngompa13@xxxxxxxxx > > == 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. +1 This is very similar to what I suggested in https://src.fedoraproject.org/rpms/cmake/pull-request/4 a couple of months ago. Nice work! Christoph > > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx -- Christoph Junghans Web: http://www.compphys.de _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
