<div dir="ltr">2017-12-01 5:41 GMT+01:00 Craig Scott <span dir="ltr"><<a href="mailto:craig.scott@crascit.com" target="_blank">craig.scott@crascit.com</a>></span>:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><span class="gmail-"><br><div class="gmail_quote">On Fri, Dec 1, 2017 at 11:15 AM, Domen Vrankar <span dir="ltr"><<a href="mailto:domen.vrankar@gmail.com" target="_blank">domen.vrankar@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">2017-11-29 17:07 GMT+01:00 DKLind <span dir="ltr"><<a href="mailto:davidklind@gmail.com" target="_blank">davidklind@gmail.com</a>></span>:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I have finally found time to work on a patch so<br>
CPACK_DEBAIN_<COMPONENT>_PACKA<wbr>GE_VERSION is recognized. I am amazed how<br>
simple the fix actually is.<br>
<br>
I plan on submitting a formal patch soon for Debian and RPM. I don't know<br>
anything about other CMake packaging features that might benefit from this<br>
patch.<br></blockquote><div><br></div><div>Hi, <br></div><div><br></div><div>I've also been working on a bit larger feature extension that would possibly be of interest to you: <a href="https://gitlab.kitware.com/cmake/cmake/merge_requests/1545" target="_blank">https://gitlab.kitware.com/cma<wbr>ke/cmake/merge_requests/1545</a><br></div><div><br></div><div>I haven't decided on implementing per component versioning since it makes no sense to version different components of the same release differently unless they are a separate project which requires more variable overrides and manual setting of components - ExternalProject seems a better alternative in such cases. Maybe your solution can convince me otherwise.</div></div></div></div></blockquote></div><div><br></div></span><div>An example where per-component versions would be really useful is if you have one large build that produces multiple products (i.e. one git repo and one CMake build). You may want to be able to create a release package for each product, but if each product has its own distinct version number, then you currently can't quite do it with CMake for some package types. I have exactly this situation at work at the moment. In one project, I get away with it because the release packages are tar balls so I just provide a custom name that embeds the version number for each product using CPACK_ARCHIVE_<component-name><wbr>_FILE_NAME. But I have other projects which produce RPMs and for those I don't currently have a solution.</div></div></div></blockquote><div><br></div><div>The thing is that components are one package split into sub-packages which are still connected under the same base package name so they should be of the same version (e.g. I'd be surprised to download Boost rpm packages that have different version for each component [filesystem, ASIO, Spirit, ...] and still claim to be the same package group/release).</div><div><br></div><div>In super/uber build multiple projects require multiple packages of which each can have sub-package components and in this case it is logical that each project has its own package name, version, release notes, debug package(s) etc.<br></div><div><br></div><div>This is what I'm trying to address with my MR that is work in progress for now and since it requires changes not just to CPack but also CMake I've pushed before I invest the time to write all the tests to see what other people think about it.</div><div><br></div><div>As DKLind already found out the addition of per component overrides for 
CPack Deb and RPM is trivial but for the past two years I've had the 
(possibly misguided) opinion that the first/trivial solution is the wrong one.<br></div><div><br></div><div>Regards,</div><div>Domen<br></div></div><br></div></div>