<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2017-12-01 16:47 GMT+01:00 DKLind <span dir="ltr"><<a href="mailto:davidklind@gmail.com" target="_blank">davidklind@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is precisely my situation. I have a large project where 50+ packages are<br>
generated. I wanted, needed, to be able to set each packages' version<br>
uniquely. Using the CPACK_DEBAIN_<COMPONENT>_<wbr>PACKAGE_VERSION variable seemed<br>
to be the correct way, except it doesn't work. My patch allows<br>
CPACK_DEBAIN_<COMPONENT>_<wbr>PACKAGE_VERSION to be recognized by CPack and it's<br>
value used when the package is created. The patch doesn't break the existing<br>
functionality of CPACK_PACKAGE_VERSION being used. It simply checks to see<br>
of CPACK_DEBAIN_<COMPONENT>_<wbr>PACKAGE_VERSION is set. If it is, use it's<br>
value. It isn't not set use the value of CPACK_PACKAGE_VERSION.<br></blockquote><div><br></div><div>This is exactly what I've described in the reply to Craig. If projects are related they should have the same version and release notes and if they aren't and are instead just depending on each other (your case) they should have a different package name with its own sub-packages, release notes and versions. Simply changing the version and release notes but still containing one base package name is confusing, hard to maintain and in my opinion abusal of sub-packages as the Linux distros that use Rpm and Deb packages know them.</div><div><br></div><div>This is a case where ExternalProject would be a valid choice but I'm guessing that you decided against it as it causes issues when the projects are still interdependent enough to warrant extension of functionality on all (some) of them at the same time. This was the case on one of the projects on which I've worked for a few years now where you have a core and different modules that are installed at different clients but not all at once (e.g. client one has modules 1, 2 and 3 while client two has 1, 3, 4 and 5). For such a project you can put everything into one project and write "make install" which sets up your entire development environment where you can test all the modules interacting with each other and make improvements on them.</div><div><br></div><div>So my patch adds an alternative to ExternalProject for such cases but still packages all of the projects as if they were stand alone projects - a superbuild.<br></div><div><br></div><div>Regards,</div><div>Domen<br></div></div><br></div></div>