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

Neal Gompa ngompa13 at gmail.com
Sun Oct 11 02:03:57 UTC 2015


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

> 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.
>
>
​I've considered doing that, but some of the upstreams I've tentatively
talked to about it didn't want to, considering Fedora to be "too special"
when SUSE/Mageia/Debian/etc "play nice" with theirs. But the rationale is
nice to know.​



> 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.
>
>
​I can certainly see that. I tend to agree when it's put like that.​



> 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.
>
>
​Actually, I think all our rpmdevtools templates need some work. ​

It would be good if we had templates that put things in place and
implemented the best practices we use today by default. Currently,
rpmdevtools seems to be stuck in RPM 4.8 or something like that in terms of
defaults. We don't use %make_build, %{buildroot} is not the default, we
don't generate Python specs in compliance with our own guidelines, and we
don't have templates for CMake, Gradle, PHP (composer), among many others.

I don't even know *what* our guidelines are for how to build packages that
use some of these systems.



> 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/
>
>



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


More information about the devel mailing list