Re: [CMake] CPack: Create debian packge for each sub-project

[Domen Vrankar]

2017-12-04 20:35 GMT+01:00 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 ")
> 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

Re: [CMake] 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 ")
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

Re: [CMake] CPack: Create debian packge for each sub-project

[Domen Vrankar]

2017-12-04 19:57 GMT+01:00 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
> 
>

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

Re: [CMake] 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
  



--
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

Re: [CMake] CPack: Create debian packge for each sub-project

[Domen Vrankar]

2017-12-01 18:04 GMT+01:00 Domen Vrankar :

> 2017-12-01 16:47 GMT+01:00 DKLind :
>
>> 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__PACKAGE_VERSION variable
>> seemed
>> to be the correct way, except it doesn't work. My patch allows
>> CPACK_DEBAIN__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__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

Re: [CMake] CPack: Create debian packge for each sub-project

[Domen Vrankar]

2017-12-01 16:47 GMT+01:00 DKLind :

> 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__PACKAGE_VERSION variable
> seemed
> to be the correct way, except it doesn't work. My patch allows
> CPACK_DEBAIN__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__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

Re: [CMake] CPack: Create debian packge for each sub-project

[Domen Vrankar]

2017-12-01 5:41 GMT+01:00 Craig Scott :

>
>
> On Fri, Dec 1, 2017 at 11:15 AM, Domen Vrankar 
> wrote:
>
>> 2017-11-29 17:07 GMT+01:00 DKLind :
>>
>>> I have finally found time to work on a patch so
>>> CPACK_DEBAIN__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__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

Re: [CMake] CPack: Create debian packge for each sub-project

[DKLind]

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__PACKAGE_VERSION variable seemed
to be the correct way, except it doesn't work. My patch allows
CPACK_DEBAIN__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__PACKAGE_VERSION is set. If it is, use it's
value. It isn't not 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

Re: [CMake] CPack: Create debian packge for each sub-project

[Craig Scott]

On Fri, Dec 1, 2017 at 11:15 AM, Domen Vrankar 
wrote:

> 2017-11-29 17:07 GMT+01:00 DKLind :
>
>> I have finally found time to work on a patch so
>> CPACK_DEBAIN__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__FILE_NAME. But I have other projects which
produce RPMs and for those I don't currently have a solution.




-- 
Craig Scott
Melbourne, Australia
https://crascit.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

Re: [CMake] CPack: Create debian packge for each sub-project

[Domen Vrankar]

2017-11-29 17:07 GMT+01:00 DKLind :

> I have finally found time to work on a patch so
> CPACK_DEBAIN__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

Re: [CMake] CPack: Create debian packge for each sub-project

[DKLind]

I have finally found time to work on a patch so
CPACK_DEBAIN__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

Re: [CMake] CPack: Create debian packge for each sub-project

[DKLind]

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}
)



--
View this message in context: 
http://cmake.3232098.n2.nabble.com/CPack-Create-debian-packge-for-each-sub-project-tp7595889p7595912.html
Sent from the CMake mailing list archive at 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

Re: [CMake] CPack: Create debian packge for each sub-project

[Craig Scott]

On Mon, Jul 24, 2017 at 6:13 AM, Gonzalo Garramuño 
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 "
>> 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
https://crascit.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

Re: [CMake] CPack: Create debian packge for each sub-project

[Gonzalo Garramuño]

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 "
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

Re: [CMake] CPack: Create debian packge for each sub-project

[Domen Vrankar]

2017-07-23 17:19 GMT+02:00 DKLind :

> Also, curious why CPACK_*COMPONENT*__DESCRIPTION is different
> from the other CPACK_*DEBIAN*__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 :

> I forgot, I also have a question about "make package". How do I build and
> package just an individual sub-project. As expected, "make "
> 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

Re: [CMake] 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 "
works to build, but there isn't a default target to package an individual
sub-project.



--
View this message in context: 
http://cmake.3232098.n2.nabble.com/CPack-Create-debian-packge-for-each-sub-project-tp7595889p7595897.html
Sent from the CMake mailing list archive at 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

Re: [CMake] 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__PACKAGE_XXX values from sub-projects'
CMakeLists.txt.

Also, curious why CPACK_*COMPONENT*__DESCRIPTION is different
from the other CPACK_*DEBIAN*__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?



--
View this message in context: 
http://cmake.3232098.n2.nabble.com/CPack-Create-debian-packge-for-each-sub-project-tp7595889p7595895.html
Sent from the CMake mailing list archive at 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

Re: [CMake] CPack: Create debian packge for each sub-project

[Domen Vrankar]

2017-07-22 1:55 GMT+02:00 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
>

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__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 -
 (called  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__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

[CMake] 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__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__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



--
View this message in context: 
http://cmake.3232098.n2.nabble.com/CPack-Create-debian-packge-for-each-sub-project-tp7595889.html
Sent from the CMake mailing list archive at 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