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

Haïkel hguemar at fedoraproject.org
Sun Oct 11 01:31:12 UTC 2015


2015-10-11 2:14 GMT+02:00 Neal Gompa <ngompa13 at gmail.com>:
>
> I pretty much wound up doing that, but I wanted to know if there was a
> reason for not having it built into the macro like Mageia and SUSE do.
>
>

Fedora's %cmake macros came first many years ago before Suse's version.

Again:
1. it has little value for packaging, we don't reuse the sources
between two package builds.
If your CMake script is broken (no install rules), you should fix it.
I may be mistaken but it seems that you're trying to fix a package by
trial and errors: detecting generated files and then install them by
hand rather than patching your CMake script. Install rules are fairly
easy to write with CMake, and these patches could be upstreamed. [1]

Yes, out-of-tree builds is a nice feature of CMake but it's
interesting as a developer, not as a packager. We have very different
workflows, explaining why this is less important for packaging.

2. it is error-prone to implicitly move to a different directory.
Put yourself in a new packager's shoes: you want to copy a file from
sources (very common example: license file) and is not aware that the
%cmake macros moves you to a different directory, then, you get to
waste time trying to "debug" this.

3. As Orion stated, you can do an out-of-tree build explicitly, which is fine.

This is the typical example where simple design is better than
"smart". As a sponsor, I appreciate that the Fedora macro just do what
it's expected to do, nothing more (least-surprise principle). Mentees
have to learn a lot of concepts, read a lot of guidelines, do not add
them the burden of "smart" macros with unexpected behaviours. It will
save you *one* line in a spec, it could save many hours for many
newbies.
If you want my opinion, implementing a cmake template in rpmdev-tools
with out-of-tree build support would be a better alternative.

Regards,
H.

[1] this discussion reminded me of a very nice introduction to RPM
packaging from Matthias Saou about RPM packaging (The Fight), the
first step being "Know your enemy : The source!".
http://freshrpms.net/docs/fight/


More information about the devel mailing list