<div dir="ltr"><div class="gmail_default" style="font-family:times new roman,serif;font-size:small"><span style="font-family:arial,sans-serif">On Sat, Oct 10, 2015 at 9:31 PM, Haïkel </span><span dir="ltr" style="font-family:arial,sans-serif"><<a href="mailto:hguemar@fedoraproject.org" target="_blank">hguemar@fedoraproject.org</a>></span><span style="font-family:arial,sans-serif"> wrote:</span><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">2015-10-11 2:14 GMT+02:00 Neal Gompa <<a href="mailto:ngompa13@gmail.com">ngompa13@gmail.com</a>>:<br>
><br>
> I pretty much wound up doing that, but I wanted to know if there was a<br>
> reason for not having it built into the macro like Mageia and SUSE do.<br>
><br>
><br>
<br>
</span>Fedora's %cmake macros came first many years ago before Suse's version.<br>
<br>
Again:<br>
1. it has little value for packaging, we don't reuse the sources<br>
between two package builds.<br>
If your CMake script is broken (no install rules), you should fix it.<br>
I may be mistaken but it seems that you're trying to fix a package by<br>
trial and errors: detecting generated files and then install them by<br>
hand rather than patching your CMake script. Install rules are fairly<br>
easy to write with CMake, and these patches could be upstreamed. [1]<br>
<br>
Yes, out-of-tree builds is a nice feature of CMake but it's<br>
interesting as a developer, not as a packager. We have very different<br>
workflows, explaining why this is less important for packaging.<br>
<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:'times new roman',serif;font-size:small">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.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. it is error-prone to implicitly move to a different directory.<br>
Put yourself in a new packager's shoes: you want to copy a file from<br>
sources (very common example: license file) and is not aware that the<br>
%cmake macros moves you to a different directory, then, you get to<br>
waste time trying to "debug" this.<br>
<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:'times new roman',serif;font-size:small">I can certainly see that. I tend to agree when it's put like that.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. As Orion stated, you can do an out-of-tree build explicitly, which is fine.<br>
<br>
This is the typical example where simple design is better than<br>
"smart". As a sponsor, I appreciate that the Fedora macro just do what<br>
it's expected to do, nothing more (least-surprise principle). Mentees<br>
have to learn a lot of concepts, read a lot of guidelines, do not add<br>
them the burden of "smart" macros with unexpected behaviours. It will<br>
save you *one* line in a spec, it could save many hours for many<br>
newbies.<br>
If you want my opinion, implementing a cmake template in rpmdev-tools<br>
with out-of-tree build support would be a better alternative.<br>
<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:'times new roman',serif;font-size:small">Actually, I think all our rpmdevtools templates need some work. </div><div class="gmail_default" style="font-family:'times new roman',serif;font-size:small"><br></div><div class="gmail_default" style="font-family:'times new roman',serif;font-size:small">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. </div><div class="gmail_default" style="font-family:'times new roman',serif;font-size:small"><br></div><div class="gmail_default" style="font-family:'times new roman',serif;font-size:small">I don't even know <i style="font-weight:bold">what</i> our guidelines are for how to build packages that use some of these systems.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Regards,<br>
H.<br>
<br>
[1] this discussion reminded me of a very nice introduction to RPM<br>
packaging from Matthias Saou about RPM packaging (The Fight), the<br>
first step being "Know your enemy : The source!".<br>
<a href="http://freshrpms.net/docs/fight/" rel="noreferrer" target="_blank">http://freshrpms.net/docs/fight/</a><br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div> </div></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">真実はいつも一つ！/ Always, there's only one truth!<br></div></div>
</div><font face="yw-402608bc37fe50adb11a5899295781aeb83d248d-f1064fbddc596fa6fe2013a674025baf--o" style="display: none;"></font></div>