2017-12-01 16:47 GMT+01:00 DKLind <davidkl...@gmail.com>: > This is precisely my situation. I have a large project where 50+ packages > are > generated. I wanted, needed, to be able to set each packages' version > uniquely. Using the CPACK_DEBAIN_<COMPONENT>_PACKAGE_VERSION variable > seemed > to be the correct way, except it doesn't work. My patch allows > CPACK_DEBAIN_<COMPONENT>_PACKAGE_VERSION to be recognized by CPack and > it's > value used when the package is created. The patch doesn't break the > existing > functionality of CPACK_PACKAGE_VERSION being used. It simply checks to see > of CPACK_DEBAIN_<COMPONENT>_PACKAGE_VERSION is set. If it is, use it's > value. It isn't not set use the value of CPACK_PACKAGE_VERSION. >
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. 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. 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. Regards, Domen
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
