Query: %cmake not doing out-of-tree builds?

Neal Gompa ngompa13 at gmail.com
Sat Oct 10 21:40:42 UTC 2015

On Sat, Oct 10, 2015 at 4:49 PM, Haïkel <hguemar at fedoraproject.org> wrote:

> 2015-10-10 22:25 GMT+02:00 Neal Gompa <ngompa13 at gmail.com>:
> > Hello all,
> >
> > Over the last few weeks, I've been working on a number of packages that
> use
> > CMake for the build system for various distros, and I've noticed
> something
> > rather peculiar. Of all the distros I've built packages for
> (Fedora/CentOS,
> > openSUSE, Mageia, Debian, and Ubuntu), only Fedora/CentOS does not
> > automatically do CMake building in a subdirectory such that the build
> > artifacts don't mix in with the source tree. Essentially, the %cmake
> macro
> > doesn't enforce builds are out-of-tree.
> >
> > Is there a particular reason for this?
> >
> According Rex who implemented the %cmake macro
> https://www.redhat.com/archives/fedora-packaging/2007-March/msg00044.html
> I must admit that I agree that out-of-tree builds is not  very useful
> in RPM packaging case, as you always scratch the build directory.
> Implementing out-of-tree builds who result in having to move between
> directories during package building which could error-prone.
> Regards,
> H.

It has come up for me as somewhat problematic, as when builds fail, it's
hard to tell what happened to the generated and pristine data, because it
seems quite a few of these make the assumption it is going to be out of
tree and happily do things that make no sense for in-source builds. What's
worse, at least one of them doesn't even implement a proper install target,
so that makes things somewhat challenging.

At the end of the day, it's just strange to me that our CMake building is
in-source instead of out of source, since the whole *point* of CMake in the
first place is to be used for out-of-source builds.

真実はいつも一つ!/ Always, there's only one truth!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20151010/784c4bbb/attachment.html>

More information about the devel mailing list