2017-12-01 18:04 GMT+01:00 Domen Vrankar <domen.vran...@gmail.com>: > 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. >
Craig, David the usual (expected) way of packaging things is (per package group versioning - currently supported and what my MR enables): product_1-component_1-1.0.0 product_1-component_2-1.0.0 product_2-component_1-3.5.7 product_2-component_2-3.5.7 And what you are suggesting is (per component versioning): distro_or_company-product_1-1.0.0 distro_or_company-product_2-3.5.7 On the product where I worked the compromise was to package: product-component_1_1-1.0.0_3.5.7 product-component_1_2-1.0.0_3.5.7 product-component_2_1-1.0.0_3.5.7 product-component_2_2-1.0.0_3.5.7 Which I would say that it's a bad solution but it gave us what we needed - group of products that can be built and tested together without a combination of ExternalProject commands and a build_all.sh script, have components but their versions increase independently. The first option is supported by the intuitive use of Linux distributions by simply running something like "sudo apt search libboost" but it's possible that the alternative way of packaging is possibly also feasible for others (and what we did is simply an ugly compromise hack when you need to hurry and don't want to extend CPack). Given all of this and if both my proposal and the alternative would be already implemented in CMake/CPack would you be using the alternative version from time to time or not? The alternative would be from my point of view confusing and would probably add additional custom CPack variable per-component override requirements but if you think that it would be useful or if my MR is too far off from where CMake should be going it would still be feasible to implement the per component version/release notes override. What do you think? Thanks, 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
