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. 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/ -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
