2015-10-11 2:14 GMT+02:00 Neal Gompa <ngompa13@xxxxxxxxx>:
>
> 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!
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
