CPack: Create debian packge for each sub-project

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

CPack: Create debian packge for each sub-project

DKLind
I have a large project and I need to create a Debian package for each sub-project (essentially each add_subdirectory).

I have been experimenting with CPack components as outlined here: https://cmake.org/cmake/help/v3.8/module/CPackComponent.html?highlight=cpack_components_grouping#variable:CPACK_COMPONENTS_GROUPING

I haven't been able to get any CPACK_DEBIAN_<COMPONENT>_PACKAGE_XXX variables to work. I've been using the syntax CPACK_DEBIAN_${PROJECT_NAME}_PACKAGE_XXX.

I'm calling install as:
install(TARGETS ${PROGRAM_NAME} DESTINATION lib COMPONENT ${PROGRAM_NAME})
This way each sub-project is a unique component.

I would expect that CPackConfig.cmake would contain an entry for each CPACK_DEBIAN_<COMPONENT>_PACKAGE_XXX variable. But, I'm seeing only variables for the last sub-project that called "include(CPack)".

Here are my requrements:
1. Each package must have a unique control file info (version, description, etc).
2. Each package filename must be ${PROGRAM_NAME}_${VERSION}_${ARCHITECTURE}.deb
Reply | Threaded
Open this post in threaded view
|

Re: CPack: Create debian packge for each sub-project

Domen Vrankar
2017-07-22 1:55 GMT+02:00 DKLind <[hidden email]>:
I have a large project and I need to create a Debian package for each
sub-project (essentially each add_subdirectory).

I have been experimenting with CPack components as outlined here:
https://cmake.org/cmake/help/v3.8/module/CPackComponent.html?highlight=cpack_components_grouping#variable:CPACK_COMPONENTS_GROUPING

Debian packaging generator specific variables are described here:
https://cmake.org/cmake/help/v3.8/module/CPackDeb.html
 
I haven't been able to get any CPACK_DEBIAN_<COMPONENT>_PACKAGE_XXX
variables to work. I've been using the syntax
CPACK_DEBIAN_${PROJECT_NAME}_PACKAGE_XXX.

I'm guessing that ${PROJECT_NAME} contains lower case characters - <COMPONENT> (called <compName> in documentation) part of the variable name is supposed to be in upper case.
 
I'm calling install as:
install(TARGETS ${PROGRAM_NAME} DESTINATION lib COMPONENT ${PROGRAM_NAME})
This way each sub-project is a unique component.

This looks fine.
 
I would expect that CPackConfig.cmake would contain an entry for each
CPACK_DEBIAN_<COMPONENT>_PACKAGE_XXX variable. But, I'm seeing only
variables for the last sub-project that called "include(CPack)".

Only the top level CMakeLists.txt should call 'include(CPack)' and the rest of the CMakeLists.txt (if they can be used stand alone) should only call it if they are the base binary dir:

if(CMAKE_CURRENT_BINARY_DIR STREQUAL CMAKE_BINARY_DIR)
    include(CPack)
endif()

The reason is that including this script generates CPackConfig.cmake and CPackSourceConfig.cmake files from already set variables.

Here are my requrements:
1. Each package must have a unique control file info (version, description,
etc).

Description part is not a problem but the version part is - currently only one version for all packages is used and can't be set per component. Using ExternalProject instead of subdirectories would be one solution, the other would be extending CPackDeb.cmake module (contribution would be welcome).
 
2. Each package filename must be
${PROGRAM_NAME}_${VERSION}_${ARCHITECTURE}.deb

For package names I'd suggest using:

set(CPACK_DEBIAN_FILE_NAME "DEB-DEFAULT")

to get the default deb package file name format but if you wish to use your naming convention you can set the per component version for each package.

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
Reply | Threaded
Open this post in threaded view
|

Re: CPack: Create debian packge for each sub-project

DKLind
Domen,

Thanks for the reply to my question. I was aware of the Debian packaging generator page and I also was already setting the component value to uppercase.

As documented, I had to use PARENT_SCOPE when setting CPACK_DEBIAN_<COMPONENT>_PACKAGE_XXX values from sub-projects' CMakeLists.txt.

Also, curious why CPACK_COMPONENT_<COMPONENT>_DESCRIPTION is different from the other CPACK_DEBIAN_<COMPONENT>_PACKAGE_XXX?

With your help, I have individual packaging working now, except for unique version. I also realize that I would like to be able to set the contributor for some packages to be unique.

I would like to contribute to CMake. I see the page https://cmake.org/gitweb?p=cmake.git;a=blob_plain;f=CONTRIBUTING.rst;hb=master. It mentions submitting contributions in patch form. Are pull requests also accepted?
Reply | Threaded
Open this post in threaded view
|

Re: CPack: Create debian packge for each sub-project

DKLind
I forgot, I also have a question about "make package". How do I build and package just an individual sub-project. As expected, "make <sub-project>" works to build, but there isn't a default target to package an individual sub-project.
Reply | Threaded
Open this post in threaded view
|

Re: CPack: Create debian packge for each sub-project

Domen Vrankar
In reply to this post by DKLind
2017-07-23 17:19 GMT+02:00 DKLind <[hidden email]>:
Also, curious why CPACK_*COMPONENT*_<COMPONENT>_DESCRIPTION is different
from the other CPACK_*DEBIAN*_<COMPONENT>_PACKAGE_XXX?

Most variables are debian package specific/allow to override general CPack variables specifically for debian packages. For e.g. package description is set to:
  if CPACK_DEBIAN_PACKAGE_DESCRIPTION # debian specific override
  else if CPACK_PACKAGE_DESCRIPTION_SUMMARY # general package description

There is no particular reason why per component version can't be overridden by a debian packager specific variable - you would usually want to have a single description for the same component no matter the package format (deb, rpm, ...).

With your help, I have individual packaging working now, except for unique
version. I also realize that I would like to be able to set the contributor
for some packages to be unique.

Per component variable for these variables was not introduced since
 
I would like to contribute to CMake. I see the page
https://cmake.org/gitweb?p=cmake.git;a=blob_plain;f=CONTRIBUTING.rst;hb=master.
It mentions submitting contributions in patch form. Are pull requests also
accepted?

As described in the link that you've provided create a gitlab account here: https://gitlab.kitware.com/cmake/cmake
and create a merge request (gitlab equivalent to pull request on github).

2017-07-23 17:37 GMT+02:00 DKLind <[hidden email]>:
I forgot, I also have a question about "make package". How do I build and
package just an individual sub-project. As expected, "make <sub-project>"
works to build, but there isn't a default target to package an individual
sub-project.
 
You can set CPACK_COMPONENTS_ALL variable to contain only the components that you wish to package:

set(CPACK_COMPONENTS_ALL applications libraries headers)

By default it's set by CPack to contain all components.

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
Reply | Threaded
Open this post in threaded view
|

Re: CPack: Create debian packge for each sub-project

Gonzalo Garramuño
In reply to this post by DKLind


El 23/07/17 a las 12:37, DKLind escribió:
> I forgot, I also have a question about "make package". How do I build and
> package just an individual sub-project. As expected, "make <sub-project>"
> works to build, but there isn't a default target to package an individual
> sub-project.
AFAIK, it is not possible. I would also like to know this for separate
packager generators. How to call "make package" on just one package
generator (like build just DEB and not RPM).

--
Gonzalo Garramuño

--

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
Reply | Threaded
Open this post in threaded view
|

Re: CPack: Create debian packge for each sub-project

Craig Scott-3


On Mon, Jul 24, 2017 at 6:13 AM, Gonzalo Garramuño <[hidden email]> wrote:


El 23/07/17 a las 12:37, DKLind escribió:
I forgot, I also have a question about "make package". How do I build and
package just an individual sub-project. As expected, "make <sub-project>"
works to build, but there isn't a default target to package an individual
sub-project.
AFAIK, it is not possible. I would also like to know this for separate packager generators. How to call "make package" on just one package generator (like build just DEB and not RPM).


If you want to pick the package generator, run cpack directly rather than "make package". You'd need to manually run just "make" first to ensure the packaged targets are built. You may want/need other options too when using some CMake generators (e.g. -C for the build configuration with Xcode or Visual Studio most likely).

make
cpack -G RPM



--
Craig Scott
Melbourne, Australia

--

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
Reply | Threaded
Open this post in threaded view
|

Re: CPack: Create debian packge for each sub-project

DKLind
In reply to this post by Domen Vrankar
Here's a little trick I learned. Executing the custom target, "make package_target target=xyz", will build the target and call cpack to create the package. Additional parameters can be passed by putting the target value in quotes (make package_target target="xyz -j4").

Executing cpack causes the target to be built. But, if you want to see the output of make, before cpack, "COMMAND make ${PARAMS}" will do that.

    set(PARAMS
        "$(if $(target),$(target))"
    )
    string(REPLACE " " ";" PARAMS ${PARAMS})

    add_custom_target(package_target
        COMMAND make ${PARAMS}
        COMMAND cpack -D CPACK_COMPONENTS_ALL=${PARAMS}
    )
Reply | Threaded
Open this post in threaded view
|

Re: CPack: Create debian packge for each sub-project

DKLind
In reply to this post by DKLind
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.



--
Sent from: http://cmake.3232098.n2.nabble.com/
--

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
Reply | Threaded
Open this post in threaded view
|

Re: CPack: Create debian packge for each sub-project

Domen Vrankar
2017-11-29 17:07 GMT+01:00 DKLind <[hidden email]>:
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/cmake/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.

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
Reply | Threaded
Open this post in threaded view
|

Re: CPack: Create debian packge for each sub-project

Craig Scott-3


On Fri, Dec 1, 2017 at 11:15 AM, Domen Vrankar <[hidden email]> wrote:
2017-11-29 17:07 GMT+01:00 DKLind <[hidden email]>:
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/cmake/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.




--
Craig Scott
Melbourne, Australia

--

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
Reply | Threaded
Open this post in threaded view
|

Re: CPack: Create debian packge for each sub-project

DKLind
This post was updated on .
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 set use the value of CPACK_PACKAGE_VERSION.



--
Sent from: http://cmake.3232098.n2.nabble.com/
--

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
Reply | Threaded
Open this post in threaded view
|

Re: CPack: Create debian packge for each sub-project

Domen Vrankar
In reply to this post by Craig Scott-3
2017-12-01 5:41 GMT+01:00 Craig Scott <[hidden email]>:


On Fri, Dec 1, 2017 at 11:15 AM, Domen Vrankar <[hidden email]> wrote:
2017-11-29 17:07 GMT+01:00 DKLind <[hidden email]>:
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/cmake/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
Reply | Threaded
Open this post in threaded view
|

Re: CPack: Create debian packge for each sub-project

Domen Vrankar
In reply to this post by DKLind
2017-12-01 16:47 GMT+01:00 DKLind <[hidden email]>:
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
Reply | Threaded
Open this post in threaded view
|

Re: CPack: Create debian packge for each sub-project

Domen Vrankar
2017-12-01 18:04 GMT+01:00 Domen Vrankar <[hidden email]>:
2017-12-01 16:47 GMT+01:00 DKLind <[hidden email]>:
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
Reply | Threaded
Open this post in threaded view
|

Re: CPack: Create debian packge for each sub-project

DKLind
Domen Vrankar wrote
> 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

This too is what my patch fixes. Attached is the patch.

CPackDeb.patch
<http://cmake.3232098.n2.nabble.com/file/t397522/CPackDeb.patch>  



--
Sent from: http://cmake.3232098.n2.nabble.com/
--

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
Reply | Threaded
Open this post in threaded view
|

Re: CPack: Create debian packge for each sub-project

Domen Vrankar
2017-12-04 19:57 GMT+01:00 DKLind <[hidden email]>:
Domen Vrankar wrote
> 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

This too is what my patch fixes. Attached is the patch.

CPackDeb.patch
<http://cmake.3232098.n2.nabble.com/file/t397522/CPackDeb.patch>

I'm a bit confused. Is there something missing in the patch?
Attached patch only adds per component version override - it doesn't even touch the multiple calls to `include(CPack)` and naming of different packages (not their components but different package names).

Could you please provide a simple example of the intended use for packaging of multiple packages with multiple sub-packages?

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
Reply | Threaded
Open this post in threaded view
|

Re: CPack: Create debian packge for each sub-project

DKLind
Domen Vrankar wrote
> I'm a bit confused. Is there something missing in the patch?
> Attached patch only adds per component version override - it doesn't even
> touch the multiple calls to `include(CPack)` and naming of different
> packages (not their components but different package names).
>
> Could you please provide a simple example of the intended use for
> packaging
> of multiple packages with multiple sub-packages?

I have a macro that each sub-project calls. See package macro below.

Each sub project calls CMake install for it's various pieces (.so, .conf,
init.d, etc.) then:
    For a simple library package:
    package(${PROJECT_NAME}
        ${LIBRARY_VERSION}
        "My library description"
    )

    For a daemon package:
    package(${PROJECT_NAME}
        ${DAEMONX_VERSION}
        "My daemonx description"
        ${CMAKE_SOURCE_DIR}/daemonx/debian/DEBIAN/conffiles;
        ${CMAKE_SOURCE_DIR}/daemonx/debian/DEBIAN/postinst;
        ${CMAKE_SOURCE_DIR}/daemonx/debian/DEBIAN/postrm;
        ${CMAKE_SOURCE_DIR}/daemonx/debian/DEBIAN/prerm
    )

The last thing the top level CMakeLists.txt does is:
    string(TOLOWER ${CMAKE_BUILD_TYPE} CMAKE_BUILD_TYPE)
    if(${CMAKE_BUILD_TYPE} STREQUAL release)
        set(CPACK_STRIP_FILES TRUE)
    endif()

    string(REGEX REPLACE "([0-9]+).*$" "\\1" BUILD_MAJOR_VERSION
${BUILD_VERSION})
    string(REGEX REPLACE "[0-9]+\\.([0-9]+).*$" "\\1" BUILD_MINOR_VERSION
${BUILD_VERSION})
    string(REGEX REPLACE "[0-9]+\\.[0-9]+\\.([0-9]+).*$" "\\1"
BUILD_PATCH_VERSION ${BUILD_VERSION})

    set(CPACK_GENERATOR DEB)
    set(CPACK_PACKAGE_VERSION_MAJOR ${BUILD_MAJOR_VERSION})
    set(CPACK_PACKAGE_VERSION_MINOR ${BUILD_MINOR_VERSION})
    set(CPACK_PACKAGE_VERSION_PATCH ${BUILD_PATCH_VERSION})
    set(CPACK_PACKAGE_VERSION ${BUILD_VERSION})
    set(CPACK_DEBIAN_PACKAGE_MAINTAINER "maintainer <[hidden email]>")
    set(CPACK_PACKAGE_VENDOR xyz)

    set(CPACK_PACKAGING_INSTALL_PREFIX ${CMAKE_INSTALL_PREFIX})

    set(CPACK_DEB_COMPONENT_INSTALL TRUE)
    set(CPACK_DEB_PACKAGE_COMPONENT TRUE)


In the macro, CPACK_DEBIAN_${TARGET}_PACKAGE_VERSION works because of the
patch.


macro(package target version description)
    string(TOUPPER ${target} TARGET)

    string(REGEX REPLACE "([0-9]+).*$" "\\1" BUILD_MAJOR_VERSION ${version})
    string(REGEX REPLACE "[0-9]+\\.([0-9]+).*$" "\\1" BUILD_MINOR_VERSION
${version})
    string(REGEX REPLACE "[0-9]+\\.[0-9]+\\.([0-9]+).*$" "\\1"
BUILD_PATCH_VERSION ${version})

    set(CPACK_DEBIAN_${TARGET}_PACKAGE_NAME ${target} CACHE STRING "package
${target}")
    set(CPACK_DEBIAN_${TARGET}_PACKAGE_VERSION ${version} CACHE STRING
"package ${target}")
    set(CPACK_DEBIAN_${TARGET}_PACKAGE_SECTION main CACHE STRING "package
${target}")
    set(CPACK_DEBIAN_${TARGET}_PACKAGE_PRIORITY standard CACHE STRING
"package ${target}")
    set(CPACK_DEBIAN_${TARGET}_PACKAGE_ARCHITECTURE
${CMAKE_SYSTEM_PROCESSOR} CACHE STRING "package ${target}")
    set(CPACK_COMPONENT_${TARGET}_DESCRIPTION ${description} CACHE STRING
"package ${target}")
    set(CPACK_DEBIAN_${TARGET}_PACKAGE_CONTROL_EXTRA ${ARGN} CACHE STRING
"package ${target}")

    set(CPACK_DEBIAN_${TARGET}_FILE_NAME
${target}_${version}_${CMAKE_PACKAGE_PLATFORM}.deb CACHE STRING "package
${target}")
endmacro()



--
Sent from: http://cmake.3232098.n2.nabble.com/
--

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
Reply | Threaded
Open this post in threaded view
|

Re: CPack: Create debian packge for each sub-project

Domen Vrankar
2017-12-04 20:35 GMT+01:00 DKLind <[hidden email]>:
Domen Vrankar wrote
> I'm a bit confused. Is there something missing in the patch?
> Attached patch only adds per component version override - it doesn't even
> touch the multiple calls to `include(CPack)` and naming of different
> packages (not their components but different package names).
>
> Could you please provide a simple example of the intended use for
> packaging
> of multiple packages with multiple sub-packages?

I have a macro that each sub-project calls. See package macro below.

Each sub project calls CMake install for it's various pieces (.so, .conf,
init.d, etc.) then:
    For a simple library package:
    package(${PROJECT_NAME}
        ${LIBRARY_VERSION}
        "My library description"
    )

    For a daemon package:
    package(${PROJECT_NAME}
        ${DAEMONX_VERSION}
        "My daemonx description"
        ${CMAKE_SOURCE_DIR}/daemonx/debian/DEBIAN/conffiles;
        ${CMAKE_SOURCE_DIR}/daemonx/debian/DEBIAN/postinst;
        ${CMAKE_SOURCE_DIR}/daemonx/debian/DEBIAN/postrm;
        ${CMAKE_SOURCE_DIR}/daemonx/debian/DEBIAN/prerm
    )

The last thing the top level CMakeLists.txt does is:
    string(TOLOWER ${CMAKE_BUILD_TYPE} CMAKE_BUILD_TYPE)
    if(${CMAKE_BUILD_TYPE} STREQUAL release)
        set(CPACK_STRIP_FILES TRUE)
    endif()

    string(REGEX REPLACE "([0-9]+).*$" "\\1" BUILD_MAJOR_VERSION
${BUILD_VERSION})
    string(REGEX REPLACE "[0-9]+\\.([0-9]+).*$" "\\1" BUILD_MINOR_VERSION
${BUILD_VERSION})
    string(REGEX REPLACE "[0-9]+\\.[0-9]+\\.([0-9]+).*$" "\\1"
BUILD_PATCH_VERSION ${BUILD_VERSION})

    set(CPACK_GENERATOR DEB)
    set(CPACK_PACKAGE_VERSION_MAJOR ${BUILD_MAJOR_VERSION})
    set(CPACK_PACKAGE_VERSION_MINOR ${BUILD_MINOR_VERSION})
    set(CPACK_PACKAGE_VERSION_PATCH ${BUILD_PATCH_VERSION})
    set(CPACK_PACKAGE_VERSION ${BUILD_VERSION})
    set(CPACK_DEBIAN_PACKAGE_MAINTAINER "maintainer <[hidden email]>")
    set(CPACK_PACKAGE_VENDOR xyz)

    set(CPACK_PACKAGING_INSTALL_PREFIX ${CMAKE_INSTALL_PREFIX})

    set(CPACK_DEB_COMPONENT_INSTALL TRUE)
    set(CPACK_DEB_PACKAGE_COMPONENT TRUE)


In the macro, CPACK_DEBIAN_${TARGET}_PACKAGE_VERSION works because of the
patch.


macro(package target version description)
    string(TOUPPER ${target} TARGET)

    string(REGEX REPLACE "([0-9]+).*$" "\\1" BUILD_MAJOR_VERSION ${version})
    string(REGEX REPLACE "[0-9]+\\.([0-9]+).*$" "\\1" BUILD_MINOR_VERSION
${version})
    string(REGEX REPLACE "[0-9]+\\.[0-9]+\\.([0-9]+).*$" "\\1"
BUILD_PATCH_VERSION ${version})

    set(CPACK_DEBIAN_${TARGET}_PACKAGE_NAME ${target} CACHE STRING "package
${target}")
    set(CPACK_DEBIAN_${TARGET}_PACKAGE_VERSION ${version} CACHE STRING
"package ${target}")
    set(CPACK_DEBIAN_${TARGET}_PACKAGE_SECTION main CACHE STRING "package
${target}")
    set(CPACK_DEBIAN_${TARGET}_PACKAGE_PRIORITY standard CACHE STRING
"package ${target}")
    set(CPACK_DEBIAN_${TARGET}_PACKAGE_ARCHITECTURE
${CMAKE_SYSTEM_PROCESSOR} CACHE STRING "package ${target}")
    set(CPACK_COMPONENT_${TARGET}_DESCRIPTION ${description} CACHE STRING
"package ${target}")
    set(CPACK_DEBIAN_${TARGET}_PACKAGE_CONTROL_EXTRA ${ARGN} CACHE STRING
"package ${target}")

    set(CPACK_DEBIAN_${TARGET}_FILE_NAME
${target}_${version}_${CMAKE_PACKAGE_PLATFORM}.deb CACHE STRING "package
${target}")
endmacro()

Try using this on CPackRPM with debuginfo packages or rpm default naming convention enabled (with this second part it's the same with CPackDeb apckages) - these are just two parts that you break that immediately come to mind.
Now you have to rename every package by hand, require a non standard macro just to set things up, you forfeit instead of gain automation (e.g. auto component deduction from install commands, package naming...). And you still cant override all the variables (e.g. maintainer).

While this might be enough for your use case and CPackDeb it wouldn't play nice with all CPackRPM features so it would cause them to diverge even further.

I'm still not convinced that it's worth it.

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