2017-12-01 5:41 GMT+01:00 Craig Scott <craig.sc...@crascit.com>: > > > On Fri, Dec 1, 2017 at 11:15 AM, Domen Vrankar <domen.vran...@gmail.com> > wrote: > >> 2017-11-29 17:07 GMT+01:00 DKLind <davidkl...@gmail.com>: >> >>> I have finally found time to work on a patch so >>> CPACK_DEBAIN_<COMPONENT>_PACKAGE_VERSION is recognized. I am amazed how >>> simple the fix actually is. >>> >>> I plan on submitting a formal patch soon for Debian and RPM. I don't know >>> anything about other CMake packaging features that might benefit from >>> this >>> patch. >>> >> >> Hi, >> >> I've also been working on a bit larger feature extension that would >> possibly be of interest to you: https://gitlab.kitware.com/cma >> ke/cmake/merge_requests/1545 >> >> 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. >> > > 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>_FILE_NAME. But I have other projects which > produce RPMs and for those I don't currently have a solution. >
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). 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. 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. 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. 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
