On Mon, Jun 15, 2020 at 8:22 PM Kevin Kofler <kevin.kofler@xxxxxxxxx> wrote:
>
> Ben Cotton wrote:
> > == 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
>
> How does this affect the many packages that already build in a separate
> build folder manually? There are even several specfile templates that
> contain the boilerplate for that.
>
If they build a separate folder manually and are already using the
VPATH macros, then there's no change. If they're using a different
structure, we can adapt them to the standard VPATH macros, and do
other adjustments as needed.
> And why is it worth making a potentially incompatible change to the %cmake
> macro when it can already be done with the existing one?
>
Defaults matter. And upstreams complain about us not doing out of tree
builds by default. Some projects even intentionally break in-source
builds and packagers shouldn't struggle to figure out how to do the
right thing in that circumstance.
There's also interest in making it straightforward for bigger CMake
builds to use Ninja instead of Make for performance.
Other RPM distributions have made this change with very little pain,
this just brings us in-line with the rest of the RPM distributions.
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
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
