Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 15/05/15 23:10, Domen Vrankar a écrit : Please find attached some rework on the documentation. There is no hurry :) Applied with minor changes: http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=efab805 Thanks, Domen Hi Domen, I do not know if those patches are in master, but after searching a bit in the bugtracker, I think the following issues are now addressed: - 0013232: CPackDeb fails on dependency auto-gen if any component does not contain any ELF binaries - 0013488: Patch for CPack Debian generator (fix to the auto-dependecy support via dpkg-shlibdeps) - 0013231: CPackDeb incorrectly leaks Debian dependencies across components - 0011944: CPackDeb: Support dependencies between components/Debian packages The following is partially addressed: - 0013386: CPack-generated Debian packages do not comply to Debian policy (discovered via lintian) -- missing eg. the license file error -- I do not know about - 0013015: cpack deb generator components specify output names Best, Raffi -- 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Please find attached some rework on the documentation. There is no hurry :) Applied with minor changes: http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=efab805 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 09/05/15 12:14, Domen Vrankar a écrit : I forgot that the previous patch has not yet been merged to master so no need to hurry. Hi Domen, Please find attached some rework on the documentation. There is no hurry :) Best, Raffi From f3cdd2e6c0d80d23da77fa9e5cc5cdce45270649 Mon Sep 17 00:00:00 2001 From: Raffi Enficiaud raffi.enfici...@tuebingen.mpg.de Date: Mon, 11 May 2015 15:18:05 +0200 Subject: [PATCH] CPackDEB: reworked documentation --- Modules/CPackDeb.cmake | 155 + 1 file changed, 106 insertions(+), 49 deletions(-) diff --git a/Modules/CPackDeb.cmake b/Modules/CPackDeb.cmake index 0ccb042..a30a07e 100644 --- a/Modules/CPackDeb.cmake +++ b/Modules/CPackDeb.cmake @@ -28,29 +28,33 @@ # # .. variable:: CPACK_DEBIAN_PACKAGE_NAME # +# The Debian package summary +# # * Mandatory : YES -# * Default : CPACK_PACKAGE_NAME (lower case) +# * Default : :variable:`CPACK_PACKAGE_NAME` (lower case) # -# The debian package summary # # .. variable:: CPACK_DEBIAN_PACKAGE_VERSION # +# The Debian package version +# # * Mandatory : YES -# * Default : CPACK_PACKAGE_VERSION +# * Default : :variable:`CPACK_PACKAGE_VERSION` # -# The debian package version # # .. variable:: CPACK_DEBIAN_PACKAGE_ARCHITECTURE # +# The Debian package architecture +# # * Mandatory : YES -# * Default : Output of dpkg --print-architecture (or i386 if dpkg is not found) +# * Default : Output of :code:`dpkg --print-architecture` (or :code:`i386` +#if :code:`dpkg` is not found) # -# The debian package architecture # # .. variable:: CPACK_DEBIAN_PACKAGE_DEPENDS # CPACK_DEBIAN_COMPONENT_PACKAGE_DEPENDS # -# May be used to set deb dependencies. +# Sets the Debian dependencies of this package. # # * Mandatory : NO # * Default : @@ -64,7 +68,7 @@ #If :variable:`CPACK_DEBIAN_PACKAGE_SHLIBDEPS` or #more specifically :variable:`CPACK_DEBIAN_COMPONENT_PACKAGE_SHLIBDEPS` #is set for this component, the discovered dependencies will be appended -#to :variable:`CPACK_DEBIAN_COMPONENT_PACKAGE_DEPENDS` intead of +#to :variable:`CPACK_DEBIAN_COMPONENT_PACKAGE_DEPENDS` instead of #:variable:`CPACK_DEBIAN_PACKAGE_DEPENDS`. If #:variable:`CPACK_DEBIAN_COMPONENT_PACKAGE_DEPENDS` is an empty string, #only the automatically discovered dependencies will be set for this @@ -76,21 +80,25 @@ # # .. variable:: CPACK_DEBIAN_PACKAGE_MAINTAINER # +# The Debian package maintainer +# # * Mandatory : YES -# * Default : CPACK_PACKAGE_CONTACT +# * Default : :code:`CPACK_PACKAGE_CONTACT` # -# The debian package maintainer # # .. variable:: CPACK_DEBIAN_PACKAGE_DESCRIPTION # CPACK_COMPONENT_COMPONENT_DESCRIPTION # -# The debian package description +# The Debian package description # # * Mandatory : YES # * Default : # -#- :variable:`CPACK_DEBIAN_PACKAGE_DESCRIPTION` if set or -#- :variable:`CPACK_PACKAGE_DESCRIPTION_SUMMARY` +#- :variable:`CPACK_PACKAGE_DESCRIPTION_SUMMARY` for non-component based +# installation +#- :variable:`CPACK_DEBIAN_PACKAGE_DESCRIPTION` for component-based +# installation +# # # .. variable:: CPACK_DEBIAN_PACKAGE_SECTION # @@ -99,33 +107,40 @@ # # .. variable:: CPACK_DEBIAN_COMPRESSION_TYPE # +# The compression used for creating the Debian package. +# Possible values are: lzma, xz, bzip2 and gzip. +# # * Mandatory : YES # * Default : 'gzip' # -# Possible values are: lzma, xz, bzip2 and gzip. # # .. variable:: CPACK_DEBIAN_PACKAGE_PRIORITY # +# The Debian package priority +# # * Mandatory : YES # * Default : 'optional' # -# The debian package priority # # .. variable:: CPACK_DEBIAN_PACKAGE_HOMEPAGE # -# * Mandatory : NO -# * Default : - -# # The URL of the web site for this package, preferably (when applicable) the # site from which the original source can be obtained and any additional # upstream documentation or information may be found. -# The content of this field is a simple URL without any surrounding -# characters such as . +# +# * Mandatory : NO +# * Default : - +# +# .. note:: +# +#The content of this field is a simple URL without any surrounding +#characters such as . +# # # .. variable:: CPACK_DEBIAN_PACKAGE_SHLIBDEPS # CPACK_DEBIAN_COMPONENT_PACKAGE_SHLIBDEPS # -# May be set to ON in order to use dpkg-shlibdeps to generate +# May be set to ON in order to use :code:`dpkg-shlibdeps` to generate # better package dependency list. # # * Mandatory : NO @@ -141,92 +156,132 @@ #may fail to find your own shared libs. #See http://www.cmake.org/Wiki/CMake_RPATH_handling. # -# .. variable:: CPACK_DEBIAN_PACKAGE_DEBUG # -# * Mandatory : NO -# * Default : - +# .. variable:: CPACK_DEBIAN_PACKAGE_DEBUG # # May be set when invoking cpack in order to trace debug information # during CPackDeb run. # +# * Mandatory : NO +# *
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
It would have been hard to ship a missing binary in the patch :) True :) Apparently in this package https://packages.debian.org/fr/sid/dpkg-dev that comes also with build-essential I actually prefer having one vanilla installation for basic testing so I'll stick with it. BTW, is it the intended behaviour to log message(...) from CPackDeb.cmake onto stderr? That's the default way of printing out with message(...) command so I'm not certain if that can be changed with mode but since for years the entire module prints to stderr I'm not certain if changing that would be a smart thing to do. Next I'll take a look at you documentation patch and the comments that came along it that mail. Many thanks! since it is only one file to merge, I can do that as well. I won't be working on that until tonight (10-11 pm and I think we're in the same time zone) so if you'd like you can send a new patch. I've already merged parts of it with other commits. Regarding the CPACK_PACKAGE_CONTACT not being used elsewhere - there's a request for similar functionality in CPackRPM so I intend to use it there as well. It should stay. 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
I forgot that the previous patch has not yet been merged to master so no need to hurry. Thanks, Domen 2015-05-09 10:58 GMT+02:00, Domen Vrankar domen.vran...@gmail.com: It would have been hard to ship a missing binary in the patch :) True :) Apparently in this package https://packages.debian.org/fr/sid/dpkg-dev that comes also with build-essential I actually prefer having one vanilla installation for basic testing so I'll stick with it. BTW, is it the intended behaviour to log message(...) from CPackDeb.cmake onto stderr? That's the default way of printing out with message(...) command so I'm not certain if that can be changed with mode but since for years the entire module prints to stderr I'm not certain if changing that would be a smart thing to do. Next I'll take a look at you documentation patch and the comments that came along it that mail. Many thanks! since it is only one file to merge, I can do that as well. I won't be working on that until tonight (10-11 pm and I think we're in the same time zone) so if you'd like you can send a new patch. I've already merged parts of it with other commits. Regarding the CPACK_PACKAGE_CONTACT not being used elsewhere - there's a request for similar functionality in CPackRPM so I intend to use it there as well. It should stay. 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 08/05/15 07:54, Domen Vrankar a écrit : Would you please add set( CPACK_DEBIAN_PACKAGE_DEBUG ON) to the file MyLibCPackConfig-splitted-components-depend2.cmake.in so that we also have the debug logs? I currently don't have access to my computer so I'll send you that in about a week. Sorry I forgot about this... Attached is verbose output and patch that I was using (slightly modified patch that you provided rebased to current master). Hi, Thanks, I will have a look this afternoon (sorry for the delay), Raffi -- 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 08/05/15 07:54, Domen Vrankar a écrit :
Would you please add
set( CPACK_DEBIAN_PACKAGE_DEBUG ON)
to the file
MyLibCPackConfig-splitted-components-depend2.cmake.in
so that we also have the debug logs?
I currently don't have access to my computer so I'll send you that in
about a week.
Sorry I forgot about this...
Attached is verbose output and patch that I was using (slightly
modified patch that you provided rebased to current master).
Hi,
In fact, CPACK_DEBIAN_PACKAGE_DEBUG ON does not produce the desired
effect. The messages executed inside the CPackDeb.cmake are redirected
for some reason to the error stream.
Would you please add the following to line 61, file
RunCPackVerifyResult.cmake
message(STATUS CPack_error=${CPack_error})
It also looks like the definition of the
CPACK_DEBIAN_APPLICATIONS_PACKAGE_DEPENDS (equals to an empty string in
the test) has precedence over the shlibdeps output.
Thanks,
Raffi
--
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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Please find attached the reworked patch and the fix (separate file) for the problem you are facing. In separate patches, I also enabled the full debug messages output in a separate patch, + some additional logs. Bitten by my own change... Nice catch. Thanks for finding this. Your changes did not fix my problem however the changes to logging made it simple to find what was wrong - missing dpkg-shlibdeps executable. I'm surprised that it doesn't come along with the vanilla Debina 7.8.0 installation. Fortunately that revealed this issue. Applied patches and fixes: http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=e3f522f Next I'll take a look at you documentation patch and the comments that came along it that mail. 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 08/05/15 07:54, Domen Vrankar a écrit :
Would you please add
set( CPACK_DEBIAN_PACKAGE_DEBUG ON)
to the file
MyLibCPackConfig-splitted-components-depend2.cmake.in
so that we also have the debug logs?
I currently don't have access to my computer so I'll send you that in
about a week.
Sorry I forgot about this...
Attached is verbose output and patch that I was using (slightly
modified patch that you provided rebased to current master).
Dear Domen,
Please find attached the reworked patch and the fix (separate file) for
the problem you are facing.
In separate patches, I also enabled the full debug messages output in a
separate patch, + some additional logs.
Thanks,
Raffi
From 0d7a383618364a4f33e9f00b94d730f9b77c53ac Mon Sep 17 00:00:00 2001
From: Domen Vrankar domen.vran...@gmail.com
Date: Fri, 8 May 2015 07:51:30 +0200
Subject: [PATCH 1/4] CPackDEB: Enabling the settings of the dependencies per
component.
---
Modules/CPackDeb.cmake | 48 +--
Tests/CMakeLists.txt | 4 +-
.../MyLibCPackConfig-components-depend1.cmake.in | 20 +
.../MyLibCPackConfig-components-depend2.cmake.in | 31
.../RunCPackVerifyResult-components-depend1.cmake | 85
.../RunCPackVerifyResult-components-depend2.cmake | 92 ++
6 files changed, 272 insertions(+), 8 deletions(-)
create mode 100644
Tests/CPackComponentsDEB/MyLibCPackConfig-components-depend1.cmake.in
create mode 100644
Tests/CPackComponentsDEB/MyLibCPackConfig-components-depend2.cmake.in
create mode 100644
Tests/CPackComponentsDEB/RunCPackVerifyResult-components-depend1.cmake
create mode 100644
Tests/CPackComponentsDEB/RunCPackVerifyResult-components-depend2.cmake
diff --git a/Modules/CPackDeb.cmake b/Modules/CPackDeb.cmake
index d1d5d09..a2e37c0 100644
--- a/Modules/CPackDeb.cmake
+++ b/Modules/CPackDeb.cmake
@@ -54,6 +54,20 @@
#
# May be used to set deb dependencies.
#
+# .. variable:: CPACK_DEBIAN_COMP_PACKAGE_DEPENDS
+#
+# * Mandatory : NO
+# * Default : :variable:`CPACK_DEBIAN_PACKAGE_DEPENDS`
+#
+# Indicates the debian package dependencies for a specific component 'COMP'.
+# This value has priority over :variable:`CPACK_DEBIAN_PACKAGE_DEPENDS`. If
+# :variable:`CPACK_DEBIAN_PACKAGE_SHLIBDEPS` is set, then the discovered
+# dependencies will be appended to `CPACK_DEBIAN_COMP_PACKAGE_DEPENDS` if
set
+# (intead of `CPACK_DEBIAN_PACKAGE_DEPENDS`).
+# The value of `CPACK_DEBIAN_COMP_PACKAGE_DEPENDS` can be set to an empty
string
+# to enable the automatic discovery of dependencies without inheriting from
+# the default value of :variable:`CPACK_DEBIAN_PACKAGE_DEPENDS`.
+#
# .. variable:: CPACK_DEBIAN_PACKAGE_MAINTAINER
#
# * Mandatory : YES
@@ -362,13 +376,6 @@ function(cpack_deb_prepare_package_vars)
# Remove blank control file
# Might not be safe if package actual contain file or directory named
debian
file(REMOVE_RECURSE ${CPACK_TEMPORARY_DIRECTORY}/debian)
-
-# Append user depend if set
-if(CPACK_DEBIAN_PACKAGE_DEPENDS)
- set(CPACK_DEBIAN_PACKAGE_DEPENDS
${CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS}, ${CPACK_DEBIAN_PACKAGE_DEPENDS})
-else()
- set(CPACK_DEBIAN_PACKAGE_DEPENDS
${CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS})
-endif()
else()
if(CPACK_DEBIAN_PACKAGE_DEBUG)
message( CPackDeb Debug: Using only user-provided depends because
package does not contain executable files that contain dynamically linked
libraries.)
@@ -426,6 +433,33 @@ function(cpack_deb_prepare_package_vars)
# Depends:
# You should set: DEBIAN_PACKAGE_DEPENDS
# TODO: automate 'objdump -p | grep NEEDED'
+
+ # if per-component dependency, overrides the global
CPACK_DEBIAN_PACKAGE_DEPENDS
+ # automatic dependency discovery will be performed afterwards.
+ if(CPACK_DEB_PACKAGE_COMPONENT)
+string(TOUPPER ${CPACK_DEB_PACKAGE_COMPONENT} _local_component_name)
+set(_component_depends_var
CPACK_DEBIAN_${_local_component_name}_PACKAGE_DEPENDS)
+
+# if set, overrides the global dependency
+if(DEFINED ${_component_depends_var})
+ set(CPACK_DEBIAN_PACKAGE_DEPENDS ${${_component_depends_var}})
+ if(CPACK_DEBIAN_PACKAGE_DEBUG)
+message(CPackDeb Debug: component '${_local_component_name}'
dependencies set to '${CPACK_DEBIAN_PACKAGE_DEPENDS}')
+ endif()
+endif()
+ endif()
+
+ # at this point, the CPACK_DEBIAN_PACKAGE_DEPENDS is properly set
+ # to the minimal dependency of the package
+ # Append automatic dependance discovery.
+ if(CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS AND NOT
CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS STREQUAL )
+if (CPACK_DEBIAN_PACKAGE_DEPENDS)
+ set (CPACK_DEBIAN_PACKAGE_DEPENDS ${CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS},
${CPACK_DEBIAN_PACKAGE_DEPENDS})
+else ()
+ set (CPACK_DEBIAN_PACKAGE_DEPENDS ${CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS})
+endif ()
+ endif()
+
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
2015-05-04 9:53 GMT+02:00 Domen Vrankar domen.vran...@gmail.com: Your test managed to find issues with previous code - automatic dependency detection doesn't work on older versions of dpkg-shlibdeps script. I wrote that a bit unclearly... With previous code I meant code that was there already before your patch. Tests now pass on all test platforms. 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Would you please add set( CPACK_DEBIAN_PACKAGE_DEBUG ON) to the file MyLibCPackConfig-splitted-components-depend2.cmake.in so that we also have the debug logs? I currently don't have access to my computer so I'll send you that in about a week. Sorry I forgot about this... Attached is verbose output and patch that I was using (slightly modified patch that you provided rebased to current master). Regards, Domen UpdateCTestConfiguration from :/home/domen/Dev/build/cmake/DartConfiguration.tcl Parse Config file:/home/domen/Dev/build/cmake/DartConfiguration.tcl Add coverage exclude regular expressions. Add coverage exclude: XCode Add coverage exclude: Kdevelop Add coverage exclude: /Source/(cm|kw)sys/ Add coverage exclude: /CMakeFiles/CMakeTmp/ Add coverage exclude: [A-Za-z]./[Qq]t/qt-.+-opensource-src UpdateCTestConfiguration from :/home/domen/Dev/build/cmake/DartConfiguration.tcl Parse Config file:/home/domen/Dev/build/cmake/DartConfiguration.tcl Test project /home/domen/Dev/build/cmake Constructing a list of tests Guessing configuration NoConfig Done constructing a list of tests Checking test dependency graph... Checking test dependency graph end test 131 Start 131: CPackComponentsDEB-components-depend2 131: Test command: /home/domen/Dev/build/cmake/bin/ctest -C NoConfig --build-and-test /media/sf_Dev/projects/cmake/Tests/CPackComponentsDEB /home/domen/Dev/build/cmake/Tests/CPackComponentsDEB/buildDEB-components-depend2 --build-generator Unix Makefiles --build-project CPackComponentsDEB --build-options -DCMAKE_MAKE_PROGRAM:FILEPATH=/usr/bin/make -DCPACK_GENERATOR:STRING=DEB -DCPACK_BINARY_DEB:BOOL=ON -DCPackDEBConfiguration=components-depend2 --graphviz=CPackComponentsDEB.dot --test-command /home/domen/Dev/build/cmake/bin/cmake -DCPackComponentsDEB_SOURCE_DIR:PATH=/media/sf_Dev/projects/cmake/Tests/CPackComponentsDEB -DCPackComponentsDEB_BINARY_DIR:PATH=/home/domen/Dev/build/cmake/Tests/CPackComponentsDEB/buildDEB-components-depend2 -DCPackGen=DEB -DCPackDEBConfiguration=components-depend2 -P /media/sf_Dev/projects/cmake/Tests/CPackComponentsDEB/RunCPackVerifyResult-components-depend2.cmake 131: Test timeout computed to be: 1500 131: Generate graphviz: /home/domen/Dev/build/cmake/Tests/CPackComponentsDEB/buildDEB-components-depend2/CPackComponentsDEB.dot 131: Writing /home/domen/Dev/build/cmake/Tests/CPackComponentsDEB/buildDEB-components-depend2/CPackComponentsDEB.dot.mylib... 131: Writing /home/domen/Dev/build/cmake/Tests/CPackComponentsDEB/buildDEB-components-depend2/CPackComponentsDEB.dot.mylibapp... 131: Writing /home/domen/Dev/build/cmake/Tests/CPackComponentsDEB/buildDEB-components-depend2/CPackComponentsDEB.dot.mylibapp2... 131: Writing /home/domen/Dev/build/cmake/Tests/CPackComponentsDEB/buildDEB-components-depend2/CPackComponentsDEB.dot.mylib.dependers... 131: Writing /home/domen/Dev/build/cmake/Tests/CPackComponentsDEB/buildDEB-components-depend2/CPackComponentsDEB.dot.mylibapp.dependers... 131: Writing /home/domen/Dev/build/cmake/Tests/CPackComponentsDEB/buildDEB-components-depend2/CPackComponentsDEB.dot.mylibapp2.dependers... 131: Writing /home/domen/Dev/build/cmake/Tests/CPackComponentsDEB/buildDEB-components-depend2/CPackComponentsDEB.dot... 131: Internal cmake changing into directory: /home/domen/Dev/build/cmake/Tests/CPackComponentsDEB/buildDEB-components-depend2 131: CMake output == 131: Configuring 131: Configuring done 131: Generating 131: Generating done 131: Build files have been written to: /home/domen/Dev/build/cmake/Tests/CPackComponentsDEB/buildDEB-components-depend2 131: End CMake output == 131: Change Dir: /home/domen/Dev/build/cmake/Tests/CPackComponentsDEB/buildDEB-components-depend2 131: 131: Run Clean Command:/usr/bin/make clean 131: 131: Run Build Command:/usr/bin/make 131: [ 16%] Building CXX object CMakeFiles/mylib.dir/mylib.cpp.o 131: [ 33%] Linking CXX static library libmylib.a 131: [ 33%] Built target mylib 131: [ 50%] Building CXX object CMakeFiles/mylibapp.dir/mylibapp.cpp.o 131: [ 66%] Linking CXX executable mylibapp 131: [ 66%] Built target mylibapp 131: [ 83%] Building CXX object CMakeFiles/mylibapp2.dir/mylibapp.cpp.o 131: [100%] Linking CXX executable mylibapp2 131: [100%] Built target mylibapp2 131: Running test command: /home/domen/Dev/build/cmake/bin/cmake -DCPackComponentsDEB_SOURCE_DIR:PATH=/media/sf_Dev/projects/cmake/Tests/CPackComponentsDEB -DCPackComponentsDEB_BINARY_DIR:PATH=/home/domen/Dev/build/cmake/Tests/CPackComponentsDEB/buildDEB-components-depend2 -DCPackGen=DEB -DCPackDEBConfiguration=components-depend2 -P /media/sf_Dev/projects/cmake/Tests/CPackComponentsDEB/RunCPackVerifyResult-components-depend2.cmake 131: Test command failed: /home/domen/Dev/build/cmake/bin/cmake 131: -- = 131: -- CTEST_FULL_OUTPUT (Avoid ctest truncation of output) 131: -- 131: CMAKE_CPACK_COMMAND =
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 02/05/15 22:19, Domen Vrankar a écrit : 2015-04-29 18:35 GMT+02:00 Domen Vrankar domen.vran...@gmail.com: Applied with minor changes - added component text from your other patch - changed CPACK_DEBIAN_PACKAGE_DESCRIPTION documentation to more accurately describe fall back options http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=2f0afff Applied patch 0001-CPackDEB-Enabling-the-dependency-auto-discovery-per-.patch to next with some changes: - added slightly modified relevant documentation fixes from your 0001-CPackDeb-reworked-documentation.patch patch - added dpkg-deb executable check before test http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=04f4284 Hi, Thank you Domen! I will send you new patches today or tomorrow for the last points. BTW, in CDash, where are the builds of next? Is it Nightly Expected or Nightly? Best, Raffi -- 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Thank you Domen! I will send you new patches today or tomorrow for the last points. BTW, in CDash, where are the builds of next? Is it Nightly Expected or Nightly? Use Nightly Expected. Not certain what Nightly section contains. Your test managed to find issues with previous code - automatic dependency detection doesn't work on older versions of dpkg-shlibdeps script. https://open.cdash.org/testDetails.php?test=332953264build=3797736 I'll try to get an older version to test on and fix it asap. 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Your test managed to find issues with previous code - automatic dependency detection doesn't work on older versions of dpkg-shlibdeps script. I wrote that a bit unclearly... With previous code I meant code that was there already before your patch. 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
2015-04-29 18:35 GMT+02:00 Domen Vrankar domen.vran...@gmail.com: Applied with minor changes - added component text from your other patch - changed CPACK_DEBIAN_PACKAGE_DESCRIPTION documentation to more accurately describe fall back options http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=2f0afff Applied patch 0001-CPackDEB-Enabling-the-dependency-auto-discovery-per-.patch to next with some changes: - added slightly modified relevant documentation fixes from your 0001-CPackDeb-reworked-documentation.patch patch - added dpkg-deb executable check before test http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=04f4284 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
I recommend git rebase: https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase-i Didn't know about interactive mode for rebase - seems allot simpler than what I described. Thanks. -- 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Please find attached the patch concerning the description per component, with the associated documentation, based on 75b0e1679c39ca824a4c49d9e1a2ae2b5f04ae06. Applied with minor changes - added component text from your other patch - changed CPACK_DEBIAN_PACKAGE_DESCRIPTION documentation to more accurately describe fall back options I will not move until you validate this patch and merge it to trunk, because otherwise I would base work on moving bases. Please note that this is only one of the features I need. On my side, I need two additional functionalities (shlibdeps + dependency per component). Patch has to pass nightly builds and then it will most likely be merged to master (merges to master are not handled by me). Usually what I do in such cases is - commit each patch separately to git - when I have to change one of them I just save commit messages, call git format-patch -5 HEAD where 5 is the amount of commits to the one that I wish to change - use git reset --soft HEAD^ to undo commits - git checkout * to undo the changes - change the patch - commit once again - reapply other patches with git apply --reject path_to_patch (if needed search for rej files and apply parts manually) For small patches this works quite well and is fairly fast - mostly without reject conflicts. For patches that were not split into smaller ones this doesn't work so you're back to manual merge... 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Domen Vrankar wrote: Usually what I do in such cases is - commit each patch separately to git - when I have to change one of them I just save commit messages, call git format-patch -5 HEAD where 5 is the amount of commits to the one that I wish to change - use git reset --soft HEAD^ to undo commits - git checkout * to undo the changes - change the patch - commit once again - reapply other patches with git apply --reject path_to_patch (if needed search for rej files and apply parts manually) I recommend git rebase: https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase-i Thanks, Steve. -- 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 28/04/15 12:23, Domen Vrankar a écrit :
Hi,
Sorry for not replying sooner.
Attachement ...
From b1e65486c99ff1023310e3c42fd509fc22e0575d Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud raffi.enfici...@mines-paris.org
Date: Wed, 29 Apr 2015 16:43:50 +0200
Subject: [PATCH] CPackDEB: adding support for description per component
---
Modules/CPackDeb.cmake | 38 --
Tests/CMakeLists.txt | 4 +-
...LibCPackConfig-components-description1.cmake.in | 25 +++
...LibCPackConfig-components-description2.cmake.in | 29
...CPackVerifyResult-components-description1.cmake | 85 ++
...CPackVerifyResult-components-description2.cmake | 85 ++
6 files changed, 259 insertions(+), 7 deletions(-)
create mode 100644
Tests/CPackComponentsDEB/MyLibCPackConfig-components-description1.cmake.in
create mode 100644
Tests/CPackComponentsDEB/MyLibCPackConfig-components-description2.cmake.in
create mode 100644
Tests/CPackComponentsDEB/RunCPackVerifyResult-components-description1.cmake
create mode 100644
Tests/CPackComponentsDEB/RunCPackVerifyResult-components-description2.cmake
diff --git a/Modules/CPackDeb.cmake b/Modules/CPackDeb.cmake
index f248a67..c146e3b 100644
--- a/Modules/CPackDeb.cmake
+++ b/Modules/CPackDeb.cmake
@@ -56,11 +56,18 @@
# The debian package maintainer
#
# .. variable:: CPACK_DEBIAN_PACKAGE_DESCRIPTION
+# CPACK_COMPONENT_COMP_DESCRIPTION
+#
+# The debian package description
#
# * Mandatory : YES
-# * Default : CPACK_PACKAGE_DESCRIPTION_SUMMARY
+# * Default :
+#
+#- :variable:`CPACK_PACKAGE_DESCRIPTION_SUMMARY` for non-component based
+# installation
+#- :variable:`CPACK_DEBIAN_PACKAGE_DESCRIPTION` for component-based
+# installation
#
-# The debian package description
#
# .. variable:: CPACK_DEBIAN_PACKAGE_SECTION
#
@@ -379,11 +386,30 @@ function(cpack_deb_prepare_package_vars)
endif()
# Description: (mandatory)
- if(NOT CPACK_DEBIAN_PACKAGE_DESCRIPTION)
-if(NOT CPACK_PACKAGE_DESCRIPTION_SUMMARY)
- message(FATAL_ERROR CPackDeb: Debian package requires a summary for a
package, set CPACK_PACKAGE_DESCRIPTION_SUMMARY or
CPACK_DEBIAN_PACKAGE_DESCRIPTION)
+ if(NOT CPACK_DEB_PACKAGE_COMPONENT)
+if(NOT CPACK_DEBIAN_PACKAGE_DESCRIPTION)
+ if(NOT CPACK_PACKAGE_DESCRIPTION_SUMMARY)
+message(FATAL_ERROR CPackDeb: Debian package requires a summary for a
package, set CPACK_PACKAGE_DESCRIPTION_SUMMARY or
CPACK_DEBIAN_PACKAGE_DESCRIPTION)
+ endif()
+ set(CPACK_DEBIAN_PACKAGE_DESCRIPTION
${CPACK_PACKAGE_DESCRIPTION_SUMMARY})
+endif()
+ else()
+string(TOUPPER ${CPACK_DEB_PACKAGE_COMPONENT} _local_component_name)
+set(component_description_var
CPACK_COMPONENT_${_local_component_name}_DESCRIPTION)
+
+# component description overrides package description
+if(${component_description_var})
+ set(CPACK_DEBIAN_PACKAGE_DESCRIPTION ${${component_description_var}})
+elseif(CPACK_DEBIAN_PACKAGE_DESCRIPTION)
+ # do nothing
+else()
+ if(NOT CPACK_PACKAGE_DESCRIPTION_SUMMARY)
+message(FATAL_ERROR CPackDeb: Debian package requires a summary for a
package, set CPACK_PACKAGE_DESCRIPTION_SUMMARY or
CPACK_DEBIAN_PACKAGE_DESCRIPTION
+ or ${component_description_var})
+ endif()
+ set(CPACK_DEBIAN_PACKAGE_DESCRIPTION
${CPACK_PACKAGE_DESCRIPTION_SUMMARY})
endif()
-set(CPACK_DEBIAN_PACKAGE_DESCRIPTION ${CPACK_PACKAGE_DESCRIPTION_SUMMARY})
+
endif()
# Section: (recommended)
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index f1379e6..3a7c16b 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -1008,7 +1008,9 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P
${CMake_SOURCE_DIR}/Utilities/Release
if(DPKG_EXECUTABLE)
unset(CPackRun_CPackDEBConfiguration_ALL_CONFIGS)
set(DEB_TEST_NAMES CPackComponentsDEB)
- set(DEB_CONFIGURATIONS_TO_TEST components-lintian-dpkgdeb-checks)
+ set(DEB_CONFIGURATIONS_TO_TEST components-lintian-dpkgdeb-checks
+ components-description1
+ components-description2)
set(CPackGen DEB)
set(CPackRun_CPackGen -DCPackGen=${CPackGen})
diff --git
a/Tests/CPackComponentsDEB/MyLibCPackConfig-components-description1.cmake.in
b/Tests/CPackComponentsDEB/MyLibCPackConfig-components-description1.cmake.in
new file mode 100644
index 000..857e19d
--- /dev/null
+++ b/Tests/CPackComponentsDEB/MyLibCPackConfig-components-description1.cmake.in
@@ -0,0 +1,25 @@
+#
+# Activate component packaging
+#
+
+if(CPACK_GENERATOR MATCHES DEB)
+ set(CPACK_DEB_COMPONENT_INSTALL ON)
+endif()
+
+#
+# Choose grouping way
+#
+#set(CPACK_COMPONENTS_ALL_GROUPS_IN_ONE_PACKAGE)
+#set(CPACK_COMPONENTS_GROUPING)
+set(CPACK_COMPONENTS_IGNORE_GROUPS 1)
+#set(CPACK_COMPONENTS_ALL_IN_ONE_PACKAGE 1)
+
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 28/04/15 12:23, Domen Vrankar a écrit : Hi, Sorry for not replying sooner. Please find attached a patch for the reworked documentation. I tried to make the doc more consistent with the CPackRPM (doc right after the variable declaration and options afterwards). I also put links for the variables and changed the formatting a bit. Thanks for the patches. You are doing a great work but please start splitting patches into subpatches... Each patch you provide is a combination of fixing one thing and adding a bunch of new things to it as well. Until one patch is added to master that patch is not finished and should not be built upon with new patches that are remotely related at best. If you intend to provide the patches like that then rework the patches yourself and resubmit all of them each time until they are applied. There are a couple of things though: - the variable CPACK_PACKAGE_CONTACT does not exist anywhere in the code I'll take a look after we finish with current patches... - right now, the CPACK_COMPONENT_COMP_DESCRIPTION is used as an equivalent to the CPACK_DEBIAN_PACKAGE_DESCRIPTION per component. If I follow the RPM conventions, those would be called CPACK_DEBIAN_COMP_PACKAGE_DESCRIPTION, which I find also better. However, in that case, should it default to CPACK_COMPONENT_COMP_DESCRIPTION or to CPACK_DEBIAN_PACKAGE_DESCRIPTION? In fact CPACK_COMPONENT_COMP_DESCRIPTION and CPACK_DEBIAN_COMP_PACKAGE_DESCRIPTION would have the same purpose and I think that it will not be obvious for the user to cope with all those variables. They would not have the same purpose - one is for setting value for all package generators at once while the other is for debian specific content. I am not a fan of generator specific overrides so I haven't bugged you with that entire hierarchy because it can be added later and because you volunteered for completely different functionality in the first place. On the other hand that is the preferred way of Brad and Eric so I intended to add the overrides later on. Regards, Domen Hi, I did not get exactly what you wanted at the end for the component based descriptions, so I left the functionality as is. So for now, I am addressing the issue CPackDEB: support for description per component. Please find attached the patch concerning the description per component, with the associated documentation, based on 75b0e1679c39ca824a4c49d9e1a2ae2b5f04ae06. I reworked the tests in the same spirit as you did for merging the previous patch to master. I will then rebase my other branches on the changes you might make. For that purpose, please send me a revision on which I can rebase my current work. I will not move until you validate this patch and merge it to trunk, because otherwise I would base work on moving bases. Please note that this is only one of the features I need. On my side, I need two additional functionalities (shlibdeps + dependency per component). Best, Raffi -- 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 28/04/15 12:23, Domen Vrankar a écrit : Hi, Sorry for not replying sooner. Please find attached a patch for the reworked documentation. I tried to make the doc more consistent with the CPackRPM (doc right after the variable declaration and options afterwards). I also put links for the variables and changed the formatting a bit. Thanks for the patches. You are doing a great work but please start splitting patches into subpatches... Each patch you provide is a combination of fixing one thing and adding a bunch of new things to it as well. Until one patch is added to master that patch is not finished and should not be built upon with new patches that are remotely related at best. If you intend to provide the patches like that then rework the patches yourself and resubmit all of them each time until they are applied. There are a couple of things though: - the variable CPACK_PACKAGE_CONTACT does not exist anywhere in the code I'll take a look after we finish with current patches... - right now, the CPACK_COMPONENT_COMP_DESCRIPTION is used as an equivalent to the CPACK_DEBIAN_PACKAGE_DESCRIPTION per component. If I follow the RPM conventions, those would be called CPACK_DEBIAN_COMP_PACKAGE_DESCRIPTION, which I find also better. However, in that case, should it default to CPACK_COMPONENT_COMP_DESCRIPTION or to CPACK_DEBIAN_PACKAGE_DESCRIPTION? In fact CPACK_COMPONENT_COMP_DESCRIPTION and CPACK_DEBIAN_COMP_PACKAGE_DESCRIPTION would have the same purpose and I think that it will not be obvious for the user to cope with all those variables. They would not have the same purpose - one is for setting value for all package generators at once while the other is for debian specific content. I am not a fan of generator specific overrides so I haven't bugged you with that entire hierarchy because it can be added later and because you volunteered for completely different functionality in the first place. On the other hand that is the preferred way of Brad and Eric so I intended to add the overrides later on. Regards, Domen Hi, I'll resubmit the patches then. Best, Raffi -- 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Hi, Sorry for not replying sooner. Please find attached a patch for the reworked documentation. I tried to make the doc more consistent with the CPackRPM (doc right after the variable declaration and options afterwards). I also put links for the variables and changed the formatting a bit. Thanks for the patches. You are doing a great work but please start splitting patches into subpatches... Each patch you provide is a combination of fixing one thing and adding a bunch of new things to it as well. Until one patch is added to master that patch is not finished and should not be built upon with new patches that are remotely related at best. If you intend to provide the patches like that then rework the patches yourself and resubmit all of them each time until they are applied. There are a couple of things though: - the variable CPACK_PACKAGE_CONTACT does not exist anywhere in the code I'll take a look after we finish with current patches... - right now, the CPACK_COMPONENT_COMP_DESCRIPTION is used as an equivalent to the CPACK_DEBIAN_PACKAGE_DESCRIPTION per component. If I follow the RPM conventions, those would be called CPACK_DEBIAN_COMP_PACKAGE_DESCRIPTION, which I find also better. However, in that case, should it default to CPACK_COMPONENT_COMP_DESCRIPTION or to CPACK_DEBIAN_PACKAGE_DESCRIPTION? In fact CPACK_COMPONENT_COMP_DESCRIPTION and CPACK_DEBIAN_COMP_PACKAGE_DESCRIPTION would have the same purpose and I think that it will not be obvious for the user to cope with all those variables. They would not have the same purpose - one is for setting value for all package generators at once while the other is for debian specific content. I am not a fan of generator specific overrides so I haven't bugged you with that entire hierarchy because it can be added later and because you volunteered for completely different functionality in the first place. On the other hand that is the preferred way of Brad and Eric so I intended to add the overrides later on. 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
I am having a look now at the changes you made on the first patch (say
75b0e1679c39ca824a4c49d9e1a2ae2b5f04ae06), file
RunCPackComponentsDEB/RunCPackVerifyResult-components-lintian-dpkgdeb-checks.cmake
Instead of finding lintian and dpkg-deb in the check file
find_program(LINTIAN_EXECUTABLE lintian)
find_program(DPKGDEB_EXECUTABLE dpkg-deb)
why not returning the string NOTFOUND in eg. the functions run_lintian
lintian_output, like this:
set(${lintian_output} NOTFOUND PARENT_SCOPE)
One reason is that tests that don't have prerequisites met should not
even be executed in the first place.
The other reason is that if I had time I would rewrite and generalize
all CPack tests to meet those expectations.
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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Hi, Would you please add set( CPACK_DEBIAN_PACKAGE_DEBUG ON) to the file MyLibCPackConfig-splitted-components-depend2.cmake.in so that we also have the debug logs? I currently don't have access to my computer so I'll send you that in about a week. BTW, I do not know what CPackDEB.cmake you are running. Is it pushed somehow? I was using master git branch with all your patches applied so it's the same code you have. I just remembered that I did an incremental build an not a fresh one so I'll have to test if it makes a difference after I get back. 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 22/04/15 23:46, Domen Vrankar a écrit : Hi, I just installed a virtual machine running Debian 7.8.0, and everything worked like a charm from the first run. I did that in the two following way: - sourced my branch https://github.com/raffienficiaud/CMake/tree/cpack_deb_refactoring - I also applied the cherry-picked from that branch onto your merge to next (8e0ecf91b3d50a0e69a00db52d1d79ca91afecc4). The only packages I installed from a default installation are vim, build-essential, git, gcc-4.7, cmake, qtcreator, clang. Putting the quotes in that case should be safer. So I cannot reproduce the error on my side. The log would be helpful. Odd... I'm not certain what the difference between our virtual machines is then. As far as I can remember I only additionally installed gcc and cmake. Maybe some updates... Attached are the generated files, verbose output and dpkg-deb -I output for application package. Thanks, Domen Hi, Would you please add set( CPACK_DEBIAN_PACKAGE_DEBUG ON) to the file MyLibCPackConfig-splitted-components-depend2.cmake.in so that we also have the debug logs? BTW, I do not know what CPackDEB.cmake you are running. Is it pushed somehow? Thanks, Best, Raffi -- 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 22/04/15 08:01, Domen Vrankar a écrit : 2015-04-21 23:38 GMT+02:00 Raffi Enficiaud raffi.enfici...@mines-paris.org: Le 21/04/15 23:01, Domen Vrankar a écrit : There are a few other things to change though. Take a look at CPackRPM man page: http://www.cmake.org/cmake/help/v3.2/module/CPackRPM.html?highlight=cpack%20rpm There is an explanation at the top that component variables override non component variables and then each non component and component variable is explained at the same time - without this the man page will get even longer as it already is without a good reason. Please change the way you wrote the documentation for your component variables. Also put the text: # The value of `CPACK_DEBIAN_COMP_PACKAGE_DEPENDS` can be set to an empty string # to enable the automatic discovery of dependencies without inheriting from # the default value of :variable:`CPACK_DEBIAN_PACKAGE_DEPENDS`. inside a Note so that it will be more visible. Thanks, Domen Hi, Please find attached a patch for the reworked documentation. I tried to make the doc more consistent with the CPackRPM (doc right after the variable declaration and options afterwards). I also put links for the variables and changed the formatting a bit. There are a couple of things though: - the variable CPACK_PACKAGE_CONTACT does not exist anywhere in the code - right now, the CPACK_COMPONENT_COMP_DESCRIPTION is used as an equivalent to the CPACK_DEBIAN_PACKAGE_DESCRIPTION per component. If I follow the RPM conventions, those would be called CPACK_DEBIAN_COMP_PACKAGE_DESCRIPTION, which I find also better. However, in that case, should it default to CPACK_COMPONENT_COMP_DESCRIPTION or to CPACK_DEBIAN_PACKAGE_DESCRIPTION? In fact CPACK_COMPONENT_COMP_DESCRIPTION and CPACK_DEBIAN_COMP_PACKAGE_DESCRIPTION would have the same purpose and I think that it will not be obvious for the user to cope with all those variables. Best, Raffi From 870d8e9e1041daf46a89f061eacd36690286687f Mon Sep 17 00:00:00 2001 From: Raffi Enficiaud raffi.enfici...@mines-paris.org Date: Fri, 24 Apr 2015 17:03:47 +0200 Subject: [PATCH] CPackDeb: reworked documentation --- Modules/CPackDeb.cmake | 224 + 1 file changed, 134 insertions(+), 90 deletions(-) diff --git a/Modules/CPackDeb.cmake b/Modules/CPackDeb.cmake index 07cd1bc..869941c 100644 --- a/Modules/CPackDeb.cmake +++ b/Modules/CPackDeb.cmake @@ -15,214 +15,258 @@ # the build system. # # CPackDeb has specific features which are controlled by the specifics -# CPACK_DEBIAN_XXX variables.You'll find a detailed usage on the wiki: -# http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#DEB_.28UNIX_only.29 +# :code:`CPACK_DEBIAN_XXX` variables. # +# :code:`CPACK_DEBIAN_COMP_` variables may be used in order to have +# **component** specific values. Note however that COMP refers +# to the **grouping name**. This may be either a component name or a +# component GROUP name. +# +# You'll find a detailed usage on the wiki: +# http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#DEB_.28UNIX_only.29 . # However as a handy reminder here comes the list of specific variables: # +# # .. variable:: CPACK_DEBIAN_PACKAGE_NAME # +# The debian package summary +# # * Mandatory : YES -# * Default : CPACK_PACKAGE_NAME (lower case) +# * Default : :variable:`CPACK_PACKAGE_NAME` (lower case) # -# The debian package summary # # .. variable:: CPACK_DEBIAN_PACKAGE_VERSION # +# The debian package version +# # * Mandatory : YES -# * Default : CPACK_PACKAGE_VERSION +# * Default : :variable:`CPACK_PACKAGE_VERSION` # -# The debian package version # # .. variable:: CPACK_DEBIAN_PACKAGE_ARCHITECTURE # +# The debian package architecture +# # * Mandatory : YES -# * Default : Output of dpkg --print-architecture (or i386 if dpkg is not found) +# * Default : Output of :code:`dpkg --print-architecture` (or :code:`i386` +#if :code:`dpkg` is not found) # -# The debian package architecture # # .. variable:: CPACK_DEBIAN_PACKAGE_DEPENDS +# CPACK_DEBIAN_COMP_PACKAGE_DEPENDS +# +# May be used to set deb dependencies. # # * Mandatory : NO -# * Default : - +# * Default : # -# May be used to set deb dependencies. +#- An empty string for non-component based installations +#- :variable:`CPACK_DEBIAN_PACKAGE_DEPENDS` for component-based +# installations. # -# .. variable:: CPACK_DEBIAN_COMP_PACKAGE_DEPENDS +# .. note:: # -# * Mandatory : NO -# * Default : :variable:`CPACK_DEBIAN_PACKAGE_DEPENDS` +#If :variable:`CPACK_DEBIAN_PACKAGE_SHLIBDEPS` or +#more specifically :variable:`CPACK_DEBIAN_COMP_PACKAGE_SHLIBDEPS` is +#set for this component, the discovered dependencies will be appended +#to :variable:`CPACK_DEBIAN_COMP_PACKAGE_DEPENDS` intead of +#:variable:`CPACK_DEBIAN_PACKAGE_DEPENDS`. If +#:variable:`CPACK_DEBIAN_COMP_PACKAGE_DEPENDS` is an empty string, only +#
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 22/04/15 08:01, Domen Vrankar a écrit :
2015-04-21 23:38 GMT+02:00 Raffi Enficiaud raffi.enfici...@mines-paris.org:
Le 21/04/15 23:01, Domen Vrankar a écrit :
Hi,
I pushed your first patch to next (I've split it into two separate
commits and made some minor cleanup changes):
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=8e0ecf9
Please find attached my last patch that allows the settings of the
dependencies per component.
I haven't finished reviewing the rest of the patches however I've
noticed that you omit quotes when setting or comparing variables.
Ok. I might help in the future if you point me on a specific line and
explain me the mistake.
Almost every line in your cmake scripts that uses set, if, string or
other commands (see the explanation below).
I wouldn't be bothering you with that and fix it myself if the test
wouldn't be failing and some other changes needed to be done.
I've also noticed that the last test in last commit is succeeding on
Ubuntu 15.04 but failing on Debian 7.8.0.
It first fails with a cryptic error (string FIND requires X variables
as input message...) on this line:
string(FIND ${dpkg_depends} lib index_libwhatever)
and after I put quotes arround ${dpkg_depends} it returns an error
that the value is an empty string.
It might help if you send me the test log file of the run.
I'll send you the data in the afternoon.
On the other
hand, I do not understand why it would be an error if ${dpkg_depends} is
an empty string. (I should still be able to find from an empty string,
shouldn't I?)
If you take a look at the code it searches for lib inside
${dpkg_depends} and then the next line checks if it found the content
and prints out an error instead (so the test fails) - that is the
expected way of your test failing.
On the other hand since the value of ${dpkg_depends} is an empty
string that value doesn't contain a value... So without quotes it is
the same as if that variable would not even exist in the above string
command (there is no empty string - the variable gets substituted by
the content of that variable so it's the same as writing nothing) -
and test failing like that is probably not what you intended.
The other reason is that set(some_var some_value other_value) creates
a list and set(some_var some_value) creates a string (list with one
value) and set(var foo bar) set(other_var ${var}) creates an array
from string... Also using set(some_var) is cryptic - it's hard to know
if you meant unset(some_var) or set(some_var )...
That is why I mentioned that you aren't using any quotes most of the
time while using variables.
Hi,
I am having a look now at the changes you made on the first patch (say
75b0e1679c39ca824a4c49d9e1a2ae2b5f04ae06), file
RunCPackComponentsDEB/RunCPackVerifyResult-components-lintian-dpkgdeb-checks.cmake
Instead of finding lintian and dpkg-deb in the check file
find_program(LINTIAN_EXECUTABLE lintian)
find_program(DPKGDEB_EXECUTABLE dpkg-deb)
why not returning the string NOTFOUND in eg. the functions run_lintian
lintian_output, like this:
set(${lintian_output} NOTFOUND PARENT_SCOPE)
If I understand correctly this should evaluate to false in an if() and
we should be able to make the distinction with an empty string. On the
other hand, we can add a variable that may return ok, notfound or
error.
What are the best practices there?
Best,
Raffi
--
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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Should I rebased on a2d36e3? The patch doesn't contain allot of changes so even if you don't the merge will be trivial so it's up to you. 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 22/04/15 23:46, Domen Vrankar a écrit : Hi, I just installed a virtual machine running Debian 7.8.0, and everything worked like a charm from the first run. I did that in the two following way: - sourced my branch https://github.com/raffienficiaud/CMake/tree/cpack_deb_refactoring - I also applied the cherry-picked from that branch onto your merge to next (8e0ecf91b3d50a0e69a00db52d1d79ca91afecc4). The only packages I installed from a default installation are vim, build-essential, git, gcc-4.7, cmake, qtcreator, clang. Putting the quotes in that case should be safer. So I cannot reproduce the error on my side. The log would be helpful. Odd... I'm not certain what the difference between our virtual machines is then. As far as I can remember I only additionally installed gcc and cmake. Maybe some updates... Attached are the generated files, verbose output and dpkg-deb -I output for application package. Thanks, Domen Thanks! I will have a deeper look at it, but right now I can see that there is no dependency line in the corresponding debian package. So it looks like the shlibdeps did not work for that component. Should I rebased on a2d36e3? Best, Raffi -- 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 22/04/15 08:01, Domen Vrankar a écrit :
2015-04-21 23:38 GMT+02:00 Raffi Enficiaud raffi.enfici...@mines-paris.org:
Le 21/04/15 23:01, Domen Vrankar a écrit :
Hi,
I pushed your first patch to next (I've split it into two separate
commits and made some minor cleanup changes):
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=8e0ecf9
Please find attached my last patch that allows the settings of the
dependencies per component.
I haven't finished reviewing the rest of the patches however I've
noticed that you omit quotes when setting or comparing variables.
Ok. I might help in the future if you point me on a specific line and
explain me the mistake.
Almost every line in your cmake scripts that uses set, if, string or
other commands (see the explanation below).
I wouldn't be bothering you with that and fix it myself if the test
wouldn't be failing and some other changes needed to be done.
I've also noticed that the last test in last commit is succeeding on
Ubuntu 15.04 but failing on Debian 7.8.0.
It first fails with a cryptic error (string FIND requires X variables
as input message...) on this line:
string(FIND ${dpkg_depends} lib index_libwhatever)
and after I put quotes arround ${dpkg_depends} it returns an error
that the value is an empty string.
It might help if you send me the test log file of the run.
I'll send you the data in the afternoon.
On the other
hand, I do not understand why it would be an error if ${dpkg_depends} is
an empty string. (I should still be able to find from an empty string,
shouldn't I?)
If you take a look at the code it searches for lib inside
${dpkg_depends} and then the next line checks if it found the content
and prints out an error instead (so the test fails) - that is the
expected way of your test failing.
On the other hand since the value of ${dpkg_depends} is an empty
string that value doesn't contain a value... So without quotes it is
the same as if that variable would not even exist in the above string
command (there is no empty string - the variable gets substituted by
the content of that variable so it's the same as writing nothing) -
and test failing like that is probably not what you intended.
The other reason is that set(some_var some_value other_value) creates
a list and set(some_var some_value) creates a string (list with one
value) and set(var foo bar) set(other_var ${var}) creates an array
from string... Also using set(some_var) is cryptic - it's hard to know
if you meant unset(some_var) or set(some_var )...
Thanks for the explanations. Which raises new questions:
How would I create empty lists then (to which I can subsequently
append)? Or check that a variable is defined? Or tell the calling
function that the output variable is set to an empty string?
Those questions should sound very naive, but this is less than obvious
to me.
For instance
string(TOUPPER ${CPACK_DEB_PACKAGE_COMPONENT} _local_component_name)
set(_component_shlibdeps_var
CPACK_DEBIAN_${_local_component_name}_PACKAGE_SHLIBDEPS)
if(DEFINED ${_component_shlibdeps_var})
...
The variable _component_shlibdeps_var clearly is defined and contains a
string that names/points a variable. In the if statement, I am checking
if the variable pointed by _component_shlibdeps_var is defined by the
user. It is not clear to me why I would put quotes in this case, there
is no risk for _component_shlibdeps_var being an empty variable.
Would it be better with/equivalent to:
if(${_component_shlibdeps_var})
?
Another example is
if(CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS AND NOT
CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS STREQUAL )
The intention is to check if CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS is
defined and is not an empty string. Here I added the 'NOT
CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS STREQUAL ' to an existing statement.
Is it equivalent to
if(NOT ${CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS} STREQUAL )
?
Again
set(CPackRun_CPackDEBConfiguration_ALL_CONFIGS)
is not the same to me as
unset(CPackRun_CPackDEBConfiguration_ALL_CONFIGS)
and actually comes from the line
set(CPackComponentsForAll_BUILD_OPTIONS)
That is why I mentioned that you aren't using any quotes most of the
time while using variables.
When I look at the changes you made,
set(options )
set(oneValueArgs FILENAME)
and from here
http://www.cmake.org/cmake/help/v3.2/module/CMakeParseArguments.html?highlight=cmake_parse_argument
I do not see the value of putting the quotes in fact, especially around
FILENAME, since there are already quotes around ${option}, etc in the
call to cmake_parse_arguments.
I haven't researched it further so if you have an option to test it on
Debian that would be great, otherwise I'll provide a fix in the
following days.
I won't be able to install a Debian box any time soon.
OK I'll send you the generated data and do the rest of the
testing/fixing of the test myself.
Please do (refer to my previous message).
There are a few other things to change
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Thanks for the explanations. Which raises new questions:
How would I create empty lists then (to which I can subsequently append)? Or
check that a variable is defined? Or tell the calling function that the
output variable is set to an empty string?
Those questions should sound very naive, but this is less than obvious to
me.
Lists in CMake are strings separated by semicolons
first_element;second_element so empty list is an empty string .
Also you don't even need to create a list variable before appending to
it - first list(APPEND ...) call will create the variable for you.
Testing if(DEFINED) tests if variable actually exists - if it's an
empty string that still means that it exists.
set(var) is the same as unset(var) - in both cases if(DEFINED var)
returns false. So writing set(var) doesn't create an empty string/list
instead it's only a more cryptic way of saying unset(var).
For eg.
set(a ) - defined to empty string
set(b ${a}) - in this case b is undefined
set(c ${a}) - in this case c is an empty string
So if you don't use quotes with set you can get odd errors so it's
better to be consistent.
For instance
string(TOUPPER ${CPACK_DEB_PACKAGE_COMPONENT} _local_component_name)
set(_component_shlibdeps_var
CPACK_DEBIAN_${_local_component_name}_PACKAGE_SHLIBDEPS)
if(DEFINED ${_component_shlibdeps_var})
...
The variable _component_shlibdeps_var clearly is defined and contains a
string that names/points a variable. In the if statement, I am checking if
the variable pointed by _component_shlibdeps_var is defined by the user. It
is not clear to me why I would put quotes in this case, there is no risk for
_component_shlibdeps_var being an empty variable.
Would it be better with/equivalent to:
if(${_component_shlibdeps_var})
?
No in this case you're right but I prefer using quotes in set()
because of empty string errors - I forget to write them from time to
time but I try to be consistent.
Another example is
if(CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS AND NOT
CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS STREQUAL )
The intention is to check if CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS is defined
and is not an empty string. Here I added the 'NOT
CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS STREQUAL ' to an existing statement. Is
it equivalent to
if(NOT ${CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS} STREQUAL )
?
Yes it's equivalent.
Again
set(CPackRun_CPackDEBConfiguration_ALL_CONFIGS)
is not the same to me as
unset(CPackRun_CPackDEBConfiguration_ALL_CONFIGS)
and actually comes from the line
set(CPackComponentsForAll_BUILD_OPTIONS)
To cmake they are the same and I had to test that first... I thought
that set(var) meant set(var ) - this was my mistake.
That is why I mentioned that you aren't using any quotes most of the
time while using variables.
When I look at the changes you made,
set(options )
set(oneValueArgs FILENAME)
and from here
http://www.cmake.org/cmake/help/v3.2/module/CMakeParseArguments.html?highlight=cmake_parse_argument
I do not see the value of putting the quotes in fact, especially around
FILENAME, since there are already quotes around ${option}, etc in the call
to cmake_parse_arguments.
set(options ) was my mistake... Now I know that it should have been
unset(options) or even better delete the variable and its use all
together.
For the FILENAME it's just consistency - using quotes where the text
is a string and doesn't represent a variable name that is used by
list, if and other functions.
Also the reason for mentioning quotes in if statements was that I did
not know that
set(var a b c)
if(${var} STREQUAL a b c)
produces correct result. I expected that it would expand to a list as
it would for set(var a b c).
So in the end other than me having allot more difficulties reviewing
the patch most of the nonquoted variables/values are not important.
The thing is that during a review when I see a non quoted string I
have to go all the way to where it was set and be certain that it
can't be assigned to an empty value, with most of the quotes in place
the review gets allot simpler for me.
Can it be in a subsequent patch or I should rework those? (reworking the
patches is more work for me.)
You can create new patches and I'll do the merge.
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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Hi, I just installed a virtual machine running Debian 7.8.0, and everything worked like a charm from the first run. I did that in the two following way: - sourced my branch https://github.com/raffienficiaud/CMake/tree/cpack_deb_refactoring - I also applied the cherry-picked from that branch onto your merge to next (8e0ecf91b3d50a0e69a00db52d1d79ca91afecc4). The only packages I installed from a default installation are vim, build-essential, git, gcc-4.7, cmake, qtcreator, clang. Putting the quotes in that case should be safer. So I cannot reproduce the error on my side. The log would be helpful. Odd... I'm not certain what the difference between our virtual machines is then. As far as I can remember I only additionally installed gcc and cmake. Maybe some updates... Attached are the generated files, verbose output and dpkg-deb -I output for application package. Thanks, Domen CPackComponentsDEB.tgz Description: GNU Zip compressed data -- 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 20/04/15 22:23, Domen Vrankar a écrit :
Is there any other thing you would like to do before I continue working on
this? Do you foresee any other change like this?
No, go ahead.
Regards,
Domen
Please find attached the first patch that adds the tests to the Debian
packaging, and performs a simple check on the md5sum file permissions
(fix also in the patch).
This patch is based on 268e008c1c448fd3652c0cf196437ede85c37880.
This patch is intended to add the test layer to the DEB packages needed
by the subsequent changes I will make. Please indicate me if there is
any issue in integrating this patch, as I will base my work on this one.
The others patches will follow on the same format (based on this one).
Best,
Raffi
From eea580aacc6f8b765c5f356d7eb3ca8225b8ea54 Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud raffi.enfici...@mines-paris.org
Date: Tue, 21 Apr 2015 10:23:23 +0200
Subject: [PATCH] New tests for the Debian packaging:
- adding functions for lintian and dpkg-deb checks
- checking the one file per component without groups configuration
- fixing a warning in lintian about the md5sum file permissions
- checking the Maintainer field in the generated packages
---
Source/CPack/cmCPackDebGenerator.cxx | 4 +
Tests/CMakeLists.txt | 36
Tests/CPackComponentsDEB/CMakeLists.txt| 106 ++
...tted-components-lintian-dpkgdeb-checks.cmake.in | 15 ++
...plitted-components-lintian-dpkgdeb-checks.cmake | 78
.../CPackComponentsDEB/RunCPackVerifyResult.cmake | 217 +
Tests/CPackComponentsDEB/license.txt | 3 +
Tests/CPackComponentsDEB/mylib.cpp | 7 +
Tests/CPackComponentsDEB/mylib.h | 1 +
Tests/CPackComponentsDEB/mylibapp.cpp | 6 +
10 files changed, 473 insertions(+)
create mode 100644 Tests/CPackComponentsDEB/CMakeLists.txt
create mode 100644
Tests/CPackComponentsDEB/MyLibCPackConfig-splitted-components-lintian-dpkgdeb-checks.cmake.in
create mode 100644
Tests/CPackComponentsDEB/RunCPackVerifyResult-splitted-components-lintian-dpkgdeb-checks.cmake
create mode 100644 Tests/CPackComponentsDEB/RunCPackVerifyResult.cmake
create mode 100644 Tests/CPackComponentsDEB/license.txt
create mode 100644 Tests/CPackComponentsDEB/mylib.cpp
create mode 100644 Tests/CPackComponentsDEB/mylib.h
create mode 100644 Tests/CPackComponentsDEB/mylibapp.cpp
diff --git a/Source/CPack/cmCPackDebGenerator.cxx
b/Source/CPack/cmCPackDebGenerator.cxx
index 1c2c001..c6d828e 100644
--- a/Source/CPack/cmCPackDebGenerator.cxx
+++ b/Source/CPack/cmCPackDebGenerator.cxx
@@ -20,6 +20,7 @@
#include cmsys/Glob.hxx
#include limits.h // USHRT_MAX
+#include sys/stat.h
// NOTE:
// A debian package .deb is simply an 'ar' archive. The only subtle difference
@@ -523,6 +524,9 @@ int cmCPackDebGenerator::createDeb()
// each line contains a eol.
// Do not end the md5sum file with yet another (invalid)
}
+
+// lintian warning otherwise
+cmSystemTools::SetPermissions(md5filename.c_str(), S_IRUSR | S_IWUSR |
S_IRGRP | S_IROTH);
cmd = this-GetOption(GEN_CPACK_DEBIAN_FAKEROOT_EXECUTABLE);
cmd += cmake_tar + tar czf control.tar.gz ./control ./md5sums;
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index b474d32..8145d91 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -1003,6 +1003,42 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P
${CMake_SOURCE_DIR}/Utilities/Release
list(APPEND TEST_BUILD_DIRS
${CMake_BINARY_DIR}/Tests/CPackComponentsForAll/build${CPackGen}-${CPackComponentWay})
endforeach()
endforeach()
+
+# debian specific
+if(DPKG_EXECUTABLE)
+set(CPackRun_CPackDEBConfiguration_ALL_CONFIGS)
+set(DEB_TEST_NAMES CPackComponentsDEB)
+set(DEB_CONFIGURATIONS_TO_TEST
splitted-components-lintian-dpkgdeb-checks)
+set(CPackGen DEB)
+set(CPackRun_CPackGen -DCPackGen=${CPackGen})
+
+foreach(CPackDEBConfiguration ${DEB_CONFIGURATIONS_TO_TEST})
+set(CPackRun_CPackDEBConfiguration
-DCPackDEBConfiguration=${CPackDEBConfiguration})
+add_test(${DEB_TEST_NAMES}-${CPackDEBConfiguration}
+ ${CMAKE_CTEST_COMMAND} -C \${CTEST_CONFIGURATION_TYPE}
+ --build-and-test
+${CMake_SOURCE_DIR}/Tests/${DEB_TEST_NAMES}
+
${CMake_BINARY_DIR}/Tests/${DEB_TEST_NAMES}/build${CPackGen}-${CPackDEBConfiguration}
+${build_generator_args}
+ --build-project CPackComponentsDEB
+ --build-options ${build_options}
+ -DCPACK_GENERATOR:STRING=${CPackGen}
+ -DCPACK_BINARY_${CPackGen}:BOOL=ON
+ ${CPackRun_CPackDEBConfiguration}
+ ${CPackRun_CPackDEBConfiguration_ALL_CONFIGS}
+
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 21/04/15 16:41, Raffi Enficiaud a écrit :
Le 21/04/15 14:36, Raffi Enficiaud a écrit :
Le 18/04/15 09:58, Raffi Enficiaud a écrit :
Le 18/04/15 09:34, Domen Vrankar a écrit :
The way you implemented it you are not covering the case:
1) CPACK_DEBIAN_PACKAGE_DESCRIPTION no set
2) CPACK_DEBIAN_PACKAGE_DESCRIPTION is set with component description
3) next component doesn't set per component description so
CPACK_DEBIAN_PACKAGE_DESCRIPTION is not reset and description of the
previous component is used
Or if 1) would be set and 3 not set you would loose the initial
description
Ok. I worked essentially on having the tests kind of functional. I will
add the cases you mentioned in new tests.
Please find attached the patch that allows a description per component.
I believe I created a test covering the issue you mentioned above.
Raffi
Please find attached the patch that enables the setting of the
dependency discovery per-component. This patch is based on the previous
one (description per component), but is rather independent. The next
patch, dependency per component, will depend on the changes made by the
attached patch.
Best,
Raffi
Please find attached my last patch that allows the settings of the
dependencies per component.
I do not know how you would like to proceed. It should not be any issue
in applying the patches in sequence from the changes you made yesterday.
Any feedback more than welcome.
Best,
Raffi
From d43784c761d4e2d23fb8242eb194c88baa808da5 Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud raffi.enfici...@tuebingen.mpg.de
Date: Tue, 21 Apr 2015 17:15:00 +0200
Subject: [PATCH] CPackDEB: Enabling the settings of the dependencies per
component.
---
Modules/CPackDeb.cmake | 49 ++--
Tests/CMakeLists.txt | 2 +
...PackConfig-splitted-components-depend1.cmake.in | 20 +
...PackConfig-splitted-components-depend2.cmake.in | 29 +++
...kVerifyResult-splitted-components-depend1.cmake | 83
...kVerifyResult-splitted-components-depend2.cmake | 91 ++
6 files changed, 268 insertions(+), 6 deletions(-)
create mode 100644
Tests/CPackComponentsDEB/MyLibCPackConfig-splitted-components-depend1.cmake.in
create mode 100644
Tests/CPackComponentsDEB/MyLibCPackConfig-splitted-components-depend2.cmake.in
create mode 100644
Tests/CPackComponentsDEB/RunCPackVerifyResult-splitted-components-depend1.cmake
create mode 100644
Tests/CPackComponentsDEB/RunCPackVerifyResult-splitted-components-depend2.cmake
diff --git a/Modules/CPackDeb.cmake b/Modules/CPackDeb.cmake
index acdb82c..07cd1bc 100644
--- a/Modules/CPackDeb.cmake
+++ b/Modules/CPackDeb.cmake
@@ -48,6 +48,20 @@
#
# May be used to set deb dependencies.
#
+# .. variable:: CPACK_DEBIAN_COMP_PACKAGE_DEPENDS
+#
+# * Mandatory : NO
+# * Default : :variable:`CPACK_DEBIAN_PACKAGE_DEPENDS`
+#
+# Indicates the debian package dependencies for a specific component 'COMP'.
+# This value has priority over :variable:`CPACK_DEBIAN_PACKAGE_DEPENDS`. If
+# :variable:`CPACK_DEBIAN_PACKAGE_SHLIBDEPS` is set, then the discovered
+# dependencies will be appended to `CPACK_DEBIAN_COMP_PACKAGE_DEPENDS` if
set
+# (intead of `CPACK_DEBIAN_PACKAGE_DEPENDS`).
+# The value of `CPACK_DEBIAN_COMP_PACKAGE_DEPENDS` can be set to an empty
string
+# to enable the automatic discovery of dependencies without inheriting from
+# the default value of :variable:`CPACK_DEBIAN_PACKAGE_DEPENDS`.
+#
# .. variable:: CPACK_DEBIAN_PACKAGE_MAINTAINER
#
# * Mandatory : YES
@@ -343,12 +357,8 @@ function(cpack_deb_prepare_package_vars)
# Might not be safe if package actual contain file or directory named
debian
file(REMOVE_RECURSE ${CPACK_TEMPORARY_DIRECTORY}/debian)
- # Append user depend if set
- if (CPACK_DEBIAN_PACKAGE_DEPENDS)
-set (CPACK_DEBIAN_PACKAGE_DEPENDS
${CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS}, ${CPACK_DEBIAN_PACKAGE_DEPENDS})
- else ()
-set (CPACK_DEBIAN_PACKAGE_DEPENDS
${CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS})
- endif ()
+ # this is too early to populate the CPACK_DEBIAN_PACKAGE_DEPENDS, as the
way to do it
+ # is configuration dependant (component, etc)
else ()
if(CPACK_DEBIAN_PACKAGE_DEBUG)
@@ -402,6 +412,33 @@ function(cpack_deb_prepare_package_vars)
# Depends:
# You should set: DEBIAN_PACKAGE_DEPENDS
# TODO: automate 'objdump -p | grep NEEDED'
+
+ # if per-component dependency, overrides the global
CPACK_DEBIAN_PACKAGE_DEPENDS
+ # automatic dependency discovery will be performed afterwards.
+ if(CPACK_DEB_PACKAGE_COMPONENT)
+string(TOUPPER ${CPACK_DEB_PACKAGE_COMPONENT} _local_component_name)
+set(_component_depends_var
CPACK_DEBIAN_${_local_component_name}_PACKAGE_DEPENDS)
+
+# if set, overrides the global dependency
+if(DEFINED ${_component_depends_var})
+ set(CPACK_DEBIAN_PACKAGE_DEPENDS
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 21/04/15 14:36, Raffi Enficiaud a écrit :
Le 18/04/15 09:58, Raffi Enficiaud a écrit :
Le 18/04/15 09:34, Domen Vrankar a écrit :
The way you implemented it you are not covering the case:
1) CPACK_DEBIAN_PACKAGE_DESCRIPTION no set
2) CPACK_DEBIAN_PACKAGE_DESCRIPTION is set with component description
3) next component doesn't set per component description so
CPACK_DEBIAN_PACKAGE_DESCRIPTION is not reset and description of the
previous component is used
Or if 1) would be set and 3 not set you would loose the initial
description
Ok. I worked essentially on having the tests kind of functional. I will
add the cases you mentioned in new tests.
Please find attached the patch that allows a description per component.
I believe I created a test covering the issue you mentioned above.
Raffi
Please find attached the patch that enables the setting of the
dependency discovery per-component. This patch is based on the previous
one (description per component), but is rather independent. The next
patch, dependency per component, will depend on the changes made by the
attached patch.
Best,
Raffi
From 618ce62aa9c9a53b1091452031c84d01c19ed45c Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud raffi.enfici...@tuebingen.mpg.de
Date: Tue, 21 Apr 2015 16:37:00 +0200
Subject: [PATCH] CPackDEB: Enabling the dependency auto-discovery per
component
---
Modules/CPackDeb.cmake | 26
Tests/CMakeLists.txt | 1 +
...kConfig-splitted-components-shlibdeps1.cmake.in | 24
...rifyResult-splitted-components-shlibdeps1.cmake | 70 ++
4 files changed, 121 insertions(+)
create mode 100644
Tests/CPackComponentsDEB/MyLibCPackConfig-splitted-components-shlibdeps1.cmake.in
create mode 100644
Tests/CPackComponentsDEB/RunCPackVerifyResult-splitted-components-shlibdeps1.cmake
diff --git a/Modules/CPackDeb.cmake b/Modules/CPackDeb.cmake
index 1a1270e..acdb82c 100644
--- a/Modules/CPackDeb.cmake
+++ b/Modules/CPackDeb.cmake
@@ -114,6 +114,15 @@
# may fail to find your own shared libs.
# See http://www.cmake.org/Wiki/CMake_RPATH_handling.
#
+# .. variable:: CPACK_DEBIAN_comp_PACKAGE_SHLIBDEPS
+#
+# * Mandatory : NO
+# * Default : CPACK_DEBIAN_PACKAGE_SHLIBDEPS
+#
+# Same as `CPACK_DEBIAN_PACKAGE_SHLIBDEPS` but for one specific component.
+# If set (either to ON or OFF) it overrides the default given by
+# `CPACK_DEBIAN_PACKAGE_SHLIBDEPS`.
+#
# .. variable:: CPACK_DEBIAN_PACKAGE_DEBUG
#
# * Mandatory : NO
@@ -245,6 +254,23 @@ function(cpack_deb_prepare_package_vars)
set(CPACK_DEBIAN_FAKEROOT_EXECUTABLE ${FAKEROOT_EXECUTABLE})
endif()
+
+ # per component automatic discover: some of the component might not have
+ # binaries.
+ if(CPACK_DEB_PACKAGE_COMPONENT)
+string(TOUPPER ${CPACK_DEB_PACKAGE_COMPONENT} _local_component_name)
+set(_component_shlibdeps_var
CPACK_DEBIAN_${_local_component_name}_PACKAGE_SHLIBDEPS)
+
+# if set, overrides the global configuration
+if(DEFINED ${_component_shlibdeps_var})
+ set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS ${${_component_shlibdeps_var}})
+ if(CPACK_DEBIAN_PACKAGE_DEBUG)
+message(CPackDeb Debug: component '${CPACK_DEB_PACKAGE_COMPONENT}'
dpkg-shlibdeps set to ${CPACK_DEBIAN_PACKAGE_SHLIBDEPS})
+ endif()
+endif()
+ endif()
+
+
if(CPACK_DEBIAN_PACKAGE_SHLIBDEPS)
# dpkg-shlibdeps is a Debian utility for generating dependency list
find_program(SHLIBDEPS_EXECUTABLE dpkg-shlibdeps)
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 2adb7e7..35683b5 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -1011,6 +1011,7 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P
${CMake_SOURCE_DIR}/Utilities/Release
set(DEB_CONFIGURATIONS_TO_TEST
splitted-components-lintian-dpkgdeb-checks
splitted-components-description1
splitted-components-description2
+ splitted-components-shlibdeps1
)
set(CPackGen DEB)
set(CPackRun_CPackGen -DCPackGen=${CPackGen})
diff --git
a/Tests/CPackComponentsDEB/MyLibCPackConfig-splitted-components-shlibdeps1.cmake.in
b/Tests/CPackComponentsDEB/MyLibCPackConfig-splitted-components-shlibdeps1.cmake.in
new file mode 100644
index 000..cfe6df5
--- /dev/null
+++
b/Tests/CPackComponentsDEB/MyLibCPackConfig-splitted-components-shlibdeps1.cmake.in
@@ -0,0 +1,24 @@
+#
+# Activate component packaging
+#
+
+if(CPACK_GENERATOR MATCHES DEB)
+ set(CPACK_DEB_COMPONENT_INSTALL ON)
+endif()
+
+#
+# Choose grouping way
+#
+#set(CPACK_COMPONENTS_ALL_GROUPS_IN_ONE_PACKAGE)
+#set(CPACK_COMPONENTS_GROUPING)
+set(CPACK_COMPONENTS_IGNORE_GROUPS 1)
+#set(CPACK_COMPONENTS_ALL_IN_ONE_PACKAGE 1)
+
+# we set shlibdeps to on
+set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS ON)
+# except for the component headers that do not contain
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 18/04/15 09:58, Raffi Enficiaud a écrit :
Le 18/04/15 09:34, Domen Vrankar a écrit :
The way you implemented it you are not covering the case:
1) CPACK_DEBIAN_PACKAGE_DESCRIPTION no set
2) CPACK_DEBIAN_PACKAGE_DESCRIPTION is set with component description
3) next component doesn't set per component description so
CPACK_DEBIAN_PACKAGE_DESCRIPTION is not reset and description of the
previous component is used
Or if 1) would be set and 3 not set you would loose the initial
description
Ok. I worked essentially on having the tests kind of functional. I will
add the cases you mentioned in new tests.
Please find attached the patch that allows a description per component.
I believe I created a test covering the issue you mentioned above.
Raffi
From 204f02edc5ac330053becb45fbec3b2ec5f2f535 Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud raffi.enfici...@tuebingen.mpg.de
Date: Tue, 21 Apr 2015 14:30:43 +0200
Subject: [PATCH] Enabling the description per components
---
Modules/CPackDeb.cmake | 37 --
Tests/CMakeLists.txt | 5 +-
...onfig-splitted-components-description1.cmake.in | 25 +++
...onfig-splitted-components-description2.cmake.in | 29
...fyResult-splitted-components-description1.cmake | 83 ++
...fyResult-splitted-components-description2.cmake | 83 ++
6 files changed, 257 insertions(+), 5 deletions(-)
create mode 100644
Tests/CPackComponentsDEB/MyLibCPackConfig-splitted-components-description1.cmake.in
create mode 100644
Tests/CPackComponentsDEB/MyLibCPackConfig-splitted-components-description2.cmake.in
create mode 100644
Tests/CPackComponentsDEB/RunCPackVerifyResult-splitted-components-description1.cmake
create mode 100644
Tests/CPackComponentsDEB/RunCPackVerifyResult-splitted-components-description2.cmake
diff --git a/Modules/CPackDeb.cmake b/Modules/CPackDeb.cmake
index f248a67..1a1270e 100644
--- a/Modules/CPackDeb.cmake
+++ b/Modules/CPackDeb.cmake
@@ -62,6 +62,16 @@
#
# The debian package description
#
+# .. variable:: CPACK_COMPONENT_COMP_DESCRIPTION
+#
+# * Mandatory : NO
+# * Default : CPACK_DEBIAN_PACKAGE_DESCRIPTION
+#
+# The debian package description for a specific component 'COMP'.
+# This description has priority over the other descriptions given by
+# :variable:`CPACK_DEBIAN_PACKAGE_DESCRIPTION` and
+# :variable:`CPACK_PACKAGE_DESCRIPTION_SUMMARY`.
+#
# .. variable:: CPACK_DEBIAN_PACKAGE_SECTION
#
# * Mandatory : YES
@@ -379,11 +389,30 @@ function(cpack_deb_prepare_package_vars)
endif()
# Description: (mandatory)
- if(NOT CPACK_DEBIAN_PACKAGE_DESCRIPTION)
-if(NOT CPACK_PACKAGE_DESCRIPTION_SUMMARY)
- message(FATAL_ERROR CPackDeb: Debian package requires a summary for a
package, set CPACK_PACKAGE_DESCRIPTION_SUMMARY or
CPACK_DEBIAN_PACKAGE_DESCRIPTION)
+ if(NOT CPACK_DEB_PACKAGE_COMPONENT)
+if(NOT CPACK_DEBIAN_PACKAGE_DESCRIPTION)
+ if(NOT CPACK_PACKAGE_DESCRIPTION_SUMMARY)
+message(FATAL_ERROR CPackDeb: Debian package requires a summary for a
package, set CPACK_PACKAGE_DESCRIPTION_SUMMARY or
CPACK_DEBIAN_PACKAGE_DESCRIPTION)
+ endif()
+ set(CPACK_DEBIAN_PACKAGE_DESCRIPTION
${CPACK_PACKAGE_DESCRIPTION_SUMMARY})
+endif()
+ else()
+string(TOUPPER ${CPACK_DEB_PACKAGE_COMPONENT} _local_component_name)
+set(component_description_var
CPACK_COMPONENT_${_local_component_name}_DESCRIPTION)
+
+# component description overrides package description
+if(${component_description_var})
+ set(CPACK_DEBIAN_PACKAGE_DESCRIPTION ${${component_description_var}})
+elseif(CPACK_DEBIAN_PACKAGE_DESCRIPTION)
+ # do nothing
+else()
+ if(NOT CPACK_PACKAGE_DESCRIPTION_SUMMARY)
+message(FATAL_ERROR CPackDeb: Debian package requires a summary for a
package, set CPACK_PACKAGE_DESCRIPTION_SUMMARY or
CPACK_DEBIAN_PACKAGE_DESCRIPTION
+ or ${component_description_var})
+ endif()
+ set(CPACK_DEBIAN_PACKAGE_DESCRIPTION
${CPACK_PACKAGE_DESCRIPTION_SUMMARY})
endif()
-set(CPACK_DEBIAN_PACKAGE_DESCRIPTION ${CPACK_PACKAGE_DESCRIPTION_SUMMARY})
+
endif()
# Section: (recommended)
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 8145d91..2adb7e7 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -1008,7 +1008,10 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P
${CMake_SOURCE_DIR}/Utilities/Release
if(DPKG_EXECUTABLE)
set(CPackRun_CPackDEBConfiguration_ALL_CONFIGS)
set(DEB_TEST_NAMES CPackComponentsDEB)
-set(DEB_CONFIGURATIONS_TO_TEST
splitted-components-lintian-dpkgdeb-checks)
+set(DEB_CONFIGURATIONS_TO_TEST
splitted-components-lintian-dpkgdeb-checks
+ splitted-components-description1
+ splitted-components-description2
+ )
set(CPackGen
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
I do not know how you would like to proceed. It should not be any issue in applying the patches in sequence from the changes you made yesterday. Hi, I just started applying and reviewing the patches. It will take me a while to get through them. I'll write to you after I'm done. 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 21/04/15 23:01, Domen Vrankar a écrit :
Hi,
I pushed your first patch to next (I've split it into two separate
commits and made some minor cleanup changes):
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=8e0ecf9
Please find attached my last patch that allows the settings of the
dependencies per component.
I haven't finished reviewing the rest of the patches however I've
noticed that you omit quotes when setting or comparing variables.
Ok. I might help in the future if you point me on a specific line and
explain me the mistake.
I've also noticed that the last test in last commit is succeeding on
Ubuntu 15.04 but failing on Debian 7.8.0.
It first fails with a cryptic error (string FIND requires X variables
as input message...) on this line:
string(FIND ${dpkg_depends} lib index_libwhatever)
and after I put quotes arround ${dpkg_depends} it returns an error
that the value is an empty string.
It might help if you send me the test log file of the run. On the other
hand, I do not understand why it would be an error if ${dpkg_depends}
is an empty string. (I should still be able to find from an empty
string, shouldn't I?)
I haven't researched it further so if you have an option to test it on
Debian that would be great, otherwise I'll provide a fix in the
following days.
I won't be able to install a Debian box any time soon. The test tests
the following setup:
- automatic dependency discovery on by default
(CPACK_DEBIAN_PACKAGE_SHLIBDEPS)
- global/default dependency set (CPACK_DEBIAN_PACKAGE_DEPENDS)
In this case, I do not want the component APPLICATION to inherit from
the general dependency, but rather let the shlibdeps tool do the work.
This is why I do the following:
set(CPACK_DEBIAN_APPLICATIONS_PACKAGE_DEPENDS )
In this case, the component dependency is set, which prevents inheriting
from CPACK_DEBIAN_PACKAGE_DEPENDS, and only the result of shlibdeps go
to the package.
Best,
Raffi Enficiaud
--
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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Hi,
I pushed your first patch to next (I've split it into two separate
commits and made some minor cleanup changes):
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=8e0ecf9
Please find attached my last patch that allows the settings of the
dependencies per component.
I haven't finished reviewing the rest of the patches however I've
noticed that you omit quotes when setting or comparing variables.
I've also noticed that the last test in last commit is succeeding on
Ubuntu 15.04 but failing on Debian 7.8.0.
It first fails with a cryptic error (string FIND requires X variables
as input message...) on this line:
string(FIND ${dpkg_depends} lib index_libwhatever)
and after I put quotes arround ${dpkg_depends} it returns an error
that the value is an empty string.
I haven't researched it further so if you have an option to test it on
Debian that would be great, otherwise I'll provide a fix in the
following days.
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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Is there any other thing you would like to do before I continue working on this? Do you foresee any other change like this? No, go ahead. 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Hi, If I am not mistaken, this does not work in the current state of the cmCpackDebGenerator.cxx (I tried of course). I wanted to know by which *magic* this could work, and also why you are suggesting me this, which lead me to this: - CPackRPM: all the RPM creation is driven by the CPackRPM.cmake itself - CPackDEB: part of package configuration is sent from the .cmake back to the cmCPackDebGenerator.cxx, and some internal functions in C++ are creating the package definition. Sorry about that... I completely forgot about that difference. The workflow is not the same, so if I scope all the variables in a function in the .cmake file, I have no way to get these variables back in the .cxx file. For the RPM package, this is fine since at the end of the CPackRPM.cmake call, the package is created. My guess is that I do not have the choice: I have to do some set/unset to avoid inter-component troubleshooting. Any suggestion more than welcome. The thing is that inside CPack you can only access variables from project CMakeLists.txt that are prefixed by CPACK_ so CPackDEB can even see CPACK_RPM* variable settings. Variables also can't be set across different CPack generators e.g. if I set a variable inside CPackRPM generator and then run both RPM and DEB generator at the same time the value won't be present in CPackDEB generator. On the other hand variables that are set in CPackDEB.cmake for one component are later visible in the other - they don't get reread from CMakeLists.txt for every pass. So setting variables inside CPackDEB.cmake is a bit dangerous. For that reason every CPackDEB variable that is used in cmCPackDebGenerator::createDeb() will have to be renamed for e.g. from CPACK_DEBIAN_PACKAGE_NAME to something like _CPACK_DEBIAN_PACKAGE_NAME and in CPackDEB.cmake those variables would have to be set(... PARENT_SCOPE) from let's say cpack_deb_generate_package() function for every pass. That way you contain variable setting and prevent future accidental overwrites. I'll write a patch for that today and push it to next. I'll also add link here so that you'll be able to use it before it gets to master. 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 18/04/15 09:34, Domen Vrankar a écrit : I added the following functionalities: - set the permissions of the md5sum to RW-R--R--, because lintian complains - added an option to set the shlibdeps per component - added an option to set the dependencies per component - added an option to set the description per component The way you implemented it you are not covering the case: 1) CPACK_DEBIAN_PACKAGE_DESCRIPTION no set 2) CPACK_DEBIAN_PACKAGE_DESCRIPTION is set with component description 3) next component doesn't set per component description so CPACK_DEBIAN_PACKAGE_DESCRIPTION is not reset and description of the previous component is used Or if 1) would be set and 3 not set you would loose the initial description There is a simple solution for variables overflowing between components - just wrap the entire code into a function (see CPackRPM cpack_rpm_generate_package() function) - since such a change messes up the entire diff (indentations) this should be an entirely separate patch. This solution would also simplify the shlibdeps patch since you would no longer need to set CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS to empty value and unset it when you no longer need it. Hi, If I am not mistaken, this does not work in the current state of the cmCpackDebGenerator.cxx (I tried of course). I wanted to know by which *magic* this could work, and also why you are suggesting me this, which lead me to this: - CPackRPM: all the RPM creation is driven by the CPackRPM.cmake itself - CPackDEB: part of package configuration is sent from the .cmake back to the cmCPackDebGenerator.cxx, and some internal functions in C++ are creating the package definition. The workflow is not the same, so if I scope all the variables in a function in the .cmake file, I have no way to get these variables back in the .cxx file. For the RPM package, this is fine since at the end of the CPackRPM.cmake call, the package is created. My guess is that I do not have the choice: I have to do some set/unset to avoid inter-component troubleshooting. Any suggestion more than welcome. Best, Raffi -- 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
I'll write a patch for that today and push it to next. I'll also add link here so that you'll be able to use it before it gets to master. Here's the patch: http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=268e008 Now it should be easy to add support for per component variables. There is an example of per component variables setting in CPackRPM starting on line 1091: foreach(_RPM_SPEC_HEADER Maybe something similar could be used in your patch so that adding new component based variables will be simpler in the future. I also took another look at your patch and noticed that you per component variables are using CPACK_DEB_PACKAGE_COMPONENT. Please convert the value to upper case before using it for per component variables. This is used for common CPACK_* variables so it would help with consistency. 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 20/04/15 19:19, Domen Vrankar a écrit : Hi, [...] - CPackRPM: all the RPM creation is driven by the CPackRPM.cmake itself - CPackDEB: part of package configuration is sent from the .cmake back to the cmCPackDebGenerator.cxx, and some internal functions in C++ are creating the package definition. Sorry about that... I completely forgot about that difference. no worries! The workflow is not the same, so if I scope all the variables in a function in the .cmake file, I have no way to get these variables back in the .cxx file. For the RPM package, this is fine since at the end of the CPackRPM.cmake call, the package is created. My guess is that I do not have the choice: I have to do some set/unset to avoid inter-component troubleshooting. Any suggestion more than welcome. The thing is that inside CPack you can only access variables from project CMakeLists.txt that are prefixed by CPACK_ so CPackDEB can even see CPACK_RPM* variable settings. Ok Variables also can't be set across different CPack generators e.g. if I set a variable inside CPackRPM generator and then run both RPM and DEB generator at the same time the value won't be present in CPackDEB generator. Ok On the other hand variables that are set in CPackDEB.cmake for one component are later visible in the other - they don't get reread from CMakeLists.txt for every pass. So setting variables inside CPackDEB.cmake is a bit dangerous. Ok. I do not understand that much the value of this feature, if this is intended. For instance, if I would like to make something available to all components (eg. some transformation of the name for instance), I would do this implementation in the .cxx file by running the loop on all components and populating an internal variable of the .cxx file. I would avoid anything that depends on the sequence of the components seen by the CPackDeb.cmake. For instance, if I have to implement the inter-component dependency, I though a possible implementation would be - loop through all the components and get back eg. the component debianized name, without generating the package (kind of dry-run) - put all those names into a map that is available to the generator - loop through all the components, with this map available, and generate the component package. On the other hand, the risks might be limited if, by /convention/, we say that all _cpack_deb_local_*** variables are reserved for local use only, initialized at the beginning of the CPackDeb.cmake (or before). I do not know that much the interface between the C++ and .cmake (for example, I do not know if this is possible to get all _cpack_deb_local_* variables, or call only one function of the .cmake instead). For that reason every CPackDEB variable that is used in cmCPackDebGenerator::createDeb() will have to be renamed for e.g. from CPACK_DEBIAN_PACKAGE_NAME to something like _CPACK_DEBIAN_PACKAGE_NAME and in CPackDEB.cmake those variables would have to be set(... PARENT_SCOPE) from let's say cpack_deb_generate_package() function for every pass. That way you contain variable setting and prevent future accidental overwrites. I'll write a patch for that today and push it to next. I'll also add link here so that you'll be able to use it before it gets to master. Sounds like a bunch of conflicts on my side :) Go ahead. Best, Raffi Raffi -- 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
On the other hand variables that are set in CPackDEB.cmake for one component are later visible in the other - they don't get reread from CMakeLists.txt for every pass. So setting variables inside CPackDEB.cmake is a bit dangerous. Ok. I do not understand that much the value of this feature, if this is intended. For instance, if I would like to make something available to all components (eg. some transformation of the name for instance), I would do this implementation in the .cxx file by running the loop on all components and populating an internal variable of the .cxx file. I would avoid anything that depends on the sequence of the components seen by the CPackDeb.cmake. I'm not certain either... It was implemented like that when I took over the maintenance of CPackRPM and CPackDEB half a year or so ago. As far as I know with RPM the decision was made that most of the functionality should be in cmake script so that eventually there would be no need for generator specific C++ code - easier to extend/modify functionality for the end users if they need to. Both approaches have their strengths and weaknesses - RPM with most of the logic in cmake script and relying on native rpm tools and configuration. - DEB with relying on C++ code and creating package without the need of deb tools. But for now I'm not trying to change their basic design. On the other hand, the risks might be limited if, by /convention/, we say that all _cpack_deb_local_*** variables are reserved for local use only, initialized at the beginning of the CPackDeb.cmake (or before). Such agreements have the limitation of being forgotten so I prefer enforcing it in code with a single base function in cmake script :) For that reason every CPackDEB variable that is used in cmCPackDebGenerator::createDeb() will have to be renamed for e.g. from CPACK_DEBIAN_PACKAGE_NAME to something like _CPACK_DEBIAN_PACKAGE_NAME and in CPackDEB.cmake those variables would have to be set(... PARENT_SCOPE) from let's say cpack_deb_generate_package() function for every pass. That way you contain variable setting and prevent future accidental overwrites. I'll write a patch for that today and push it to next. I'll also add link here so that you'll be able to use it before it gets to master. Sounds like a bunch of conflicts on my side :) Go ahead. Sorry about that :( It's just that I noticed that in the past there were many attempts at preventing accidental leakage of variables in CPackRPM and I don't want to get the same problem in CPackDEB so it's better to prevent it asap. 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 18/04/15 09:34, Domen Vrankar a écrit : I added the following functionalities: - set the permissions of the md5sum to RW-R--R--, because lintian complains - added an option to set the shlibdeps per component - added an option to set the dependencies per component - added an option to set the description per component The way you implemented it you are not covering the case: 1) CPACK_DEBIAN_PACKAGE_DESCRIPTION no set 2) CPACK_DEBIAN_PACKAGE_DESCRIPTION is set with component description 3) next component doesn't set per component description so CPACK_DEBIAN_PACKAGE_DESCRIPTION is not reset and description of the previous component is used Or if 1) would be set and 3 not set you would loose the initial description Ok. I worked essentially on having the tests kind of functional. I will add the cases you mentioned in new tests. There is a simple solution for variables overflowing between components - just wrap the entire code into a function (see CPackRPM cpack_rpm_generate_package() function) - since such a change messes up the entire diff (indentations) this should be an entirely separate patch. This solution would also simplify the shlibdeps patch since you would no longer need to set CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS to empty value and unset it when you no longer need it. Ok, I will try. - enforcing the lower case policy of Debian for package names (in the file, due to the comment # debian policy enforce lower case for package name) Since you are fixing multiple non related issues at the same time please split the patch into separate commits so that it can easier be seen which change fixes which issue. Ok. You are also leaving trailing whitespaces in patches - those should be removed. I will clean the code, yes. On the other hand, I started writing tests based on the one existing for the CPackComponentsAll, but specific to debian packages: - added a function for running lintian and checking for some errors. The md5sum permission change is now covered by that - added a function for running dpkg-deb and extracting a particular field of the package metadata. No change I made are currently covered by this function, this is what I will do next. - Having one specific check file per configuration, sharing a common .cmake providing the check functions (linitian and dpkg-deb). This would prevent the cluttering of the checks that we can observe in the CPackComponentsAll final test. I already wrote to the mailing list regarding changing where and how CPack test should be written but it will take me a few days to implement... Since you are already splitting tests into separate scripts it will be easy to move them later on. I hope so. The added value in the tests I wrote so far is the possibility to inspect the generated packages with the Debian tools, and some refactoring (I found difficult to have several config files and one check file for all generators). Sorry that was too quick. Here are the open questions: - if a component depends on another component, should we add the dependency automatically? I'd say no by default so that we don't break back compatibility unnecessarily but the feature should be enabled through a variable (e.g. CPACK_DEBIAN_COMPONENTS_AUTODEPEND ON - and also per component version). I agree with that. - What about the version of this dependency? Let's say I have components A and B, and B depends on A. I am at version X. Dependencies of A are d11, d12, d1N, Dependencies of B are d21, d22, d2P Should the generation of the package B include d2(P+1)= A (= versionX) ? For the first patch I would omit versions of dependencies. Later this can be added with additional possibility to change = to = for adding minimal required version (e.g. CPACK_DEBIAN_COMPONENT_name_DEPENDS_dependency some_version) with the possibility to enable/disable version addition. Good. Raffi. -- 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 16/04/15 22:31, Brad King a écrit :
On 04/16/2015 04:19 PM, Domen Vrankar wrote:
I've pushed the patch with minor changes to next.
http://www.cmake.org/gitweb?p=cmake.git;h=0779b679
Thanks. The fixup! mark is useful only during incremental
development of an open topic. Once a commit is in 'master'
then it should be explicitly referenced by a later fixup commit
with a normal commit message. I've revised the commit as:
CPack: Fix single component packaging
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed0b0630
I also rebased it back on the original commit and renamed the
topic to match. This makes it look like one topic that was
merged to master in the middle.
-Brad
Ok, here is a patch that shows you the advance. This is not yet a
candidate for merging to anything, but rather a support for some
discussions.
It is based on ed0b063 for this particular topic.
I added the following functionalities:
- set the permissions of the md5sum to RW-R--R--, because lintian complains
- added an option to set the shlibdeps per component
- added an option to set the dependencies per component
- added an option to set the description per component
- enforcing the lower case policy of Debian for package names (in the
file, due to the comment # debian policy enforce lower case for package
name)
On the other hand, I started writing tests based on the one existing for
the CPackComponentsAll, but specific to debian packages:
- added a function for running lintian and checking for some errors. The
md5sum permission change is now covered by that
- added a function for running dpkg-deb and extracting a particular
field of the package metadata. No change I made are currently covered by
this function, this is what I will do next.
- Having one specific check file per configuration, sharing a common
.cmake providing the check functions (linitian and dpkg-deb). This would
prevent the cluttering of the checks that we can observe in the
CPackComponentsAll final test.
Of course, your comments are more than welcome.
Best,
Raffi
From 2681e05c844eee5b77568895b5b1329f1377b05b Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud raffi.enfici...@mines-paris.org
Date: Fri, 17 Apr 2015 15:49:33 +0200
Subject: [PATCH] Debian packaging
- enabling a per component shlibdeps
- enabling a per component dependencies
- enabling a per component description
- fixing the file permissions of the auto-generated md5sum
- new tests specific to CPackDeb.cmake with lintian and dpkg-deb
---
Modules/CPackDeb.cmake | 89 +++--
Source/CPack/cmCPackDebGenerator.cxx | 8 +
Tests/CMakeLists.txt | 35
Tests/CPackComponentsDEB/CMakeLists.txt| 103 ++
...Config-one-file-per-component-no-group.cmake.in | 15 ++
...ifyResult-one-file-per-component-no-group.cmake | 78
.../CPackComponentsDEB/RunCPackVerifyResult.cmake | 217 +
Tests/CPackComponentsDEB/license.txt | 3 +
Tests/CPackComponentsDEB/mylib.cpp | 7 +
Tests/CPackComponentsDEB/mylib.h | 1 +
Tests/CPackComponentsDEB/mylibapp.cpp | 6 +
11 files changed, 550 insertions(+), 12 deletions(-)
create mode 100644 Tests/CPackComponentsDEB/CMakeLists.txt
create mode 100644
Tests/CPackComponentsDEB/MyLibCPackConfig-one-file-per-component-no-group.cmake.in
create mode 100644
Tests/CPackComponentsDEB/RunCPackVerifyResult-one-file-per-component-no-group.cmake
create mode 100644 Tests/CPackComponentsDEB/RunCPackVerifyResult.cmake
create mode 100644 Tests/CPackComponentsDEB/license.txt
create mode 100644 Tests/CPackComponentsDEB/mylib.cpp
create mode 100644 Tests/CPackComponentsDEB/mylib.h
create mode 100644 Tests/CPackComponentsDEB/mylibapp.cpp
diff --git a/Modules/CPackDeb.cmake b/Modules/CPackDeb.cmake
index 8a4fa49..647b2ae 100644
--- a/Modules/CPackDeb.cmake
+++ b/Modules/CPackDeb.cmake
@@ -104,6 +104,15 @@
# may fail to find your own shared libs.
# See http://www.cmake.org/Wiki/CMake_RPATH_handling.
#
+# .. variable:: CPACK_DEBIAN_comp_PACKAGE_SHLIBDEPS
+#
+# * Mandatory : NO
+# * Default : CPACK_DEBIAN_PACKAGE_SHLIBDEPS
+#
+# Same as `CPACK_DEBIAN_PACKAGE_SHLIBDEPS` but for one specific component.
+# If set (either to ON or OFF) it overrides the default given by
+# `CPACK_DEBIAN_PACKAGE_SHLIBDEPS`.
+#
# .. variable:: CPACK_DEBIAN_PACKAGE_DEBUG
#
# * Mandatory : NO
@@ -229,12 +238,28 @@ if(NOT DEFINED CPACK_DEBIAN_PACKAGE_SHLIBDEPS)
set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS OFF)
endif()
+set(_cpack_debian_shlibdeps_local ${CPACK_DEBIAN_PACKAGE_SHLIBDEPS})
+
find_program(FAKEROOT_EXECUTABLE fakeroot)
if(FAKEROOT_EXECUTABLE)
set(CPACK_DEBIAN_FAKEROOT_EXECUTABLE ${FAKEROOT_EXECUTABLE})
endif()
-if(CPACK_DEBIAN_PACKAGE_SHLIBDEPS)
+if(CPACK_DEB_PACKAGE_COMPONENT)
+ set(_component_shlibdeps_var
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 17/04/15 15:50, Raffi Enficiaud a écrit : Le 16/04/15 22:31, Brad King a écrit : On 04/16/2015 04:19 PM, Domen Vrankar wrote: I've pushed the patch with minor changes to next. http://www.cmake.org/gitweb?p=cmake.git;h=0779b679 Thanks. The fixup! mark is useful only during incremental development of an open topic. Once a commit is in 'master' then it should be explicitly referenced by a later fixup commit with a normal commit message. I've revised the commit as: CPack: Fix single component packaging http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed0b0630 I also rebased it back on the original commit and renamed the topic to match. This makes it look like one topic that was merged to master in the middle. -Brad Ok, here is a patch that shows you the advance. This is not yet a candidate for merging to anything, but rather a support for some discussions. It is based on ed0b063 for this particular topic. I added the following functionalities: - set the permissions of the md5sum to RW-R--R--, because lintian complains - added an option to set the shlibdeps per component - added an option to set the dependencies per component - added an option to set the description per component - enforcing the lower case policy of Debian for package names (in the file, due to the comment # debian policy enforce lower case for package name) On the other hand, I started writing tests based on the one existing for the CPackComponentsAll, but specific to debian packages: - added a function for running lintian and checking for some errors. The md5sum permission change is now covered by that - added a function for running dpkg-deb and extracting a particular field of the package metadata. No change I made are currently covered by this function, this is what I will do next. - Having one specific check file per configuration, sharing a common .cmake providing the check functions (linitian and dpkg-deb). This would prevent the cluttering of the checks that we can observe in the CPackComponentsAll final test. Of course, your comments are more than welcome. Sorry that was too quick. Here are the open questions: - if a component depends on another component, should we add the dependency automatically? - What about the version of this dependency? Let's say I have components A and B, and B depends on A. I am at version X. Dependencies of A are d11, d12, d1N, Dependencies of B are d21, d22, d2P Should the generation of the package B include d2(P+1)= A (= versionX) ? Best, Raffi -- 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 09/03/11 14:29, Mantis Bug Tracker a écrit : The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=11944 == Reported By:Martin Konrad Assigned To: == Project:CMake Issue ID: 11944 Category: CPack Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2011-03-09 08:29 EST Last Modified: 2011-03-09 08:29 EST == Summary:CPackDeb: Support dependencies between components/Debian packages Description: The patch provided in http://public.kitware.com/Bug/view.php?id=11655 does not transform the dependencies between CMake components into dependencies between the resulting Debian packages. == Issue History Date ModifiedUsername FieldChange == 2011-03-09 08:29 Martin Konrad New Issue == Hi all, I was wondering if this issue has been addressed so far. It is also related to this thread I think, which provides a possible implementation: - http://www.cmake.org/pipermail/cmake/2012-May/050292.html - http://cmake.3232098.n2.nabble.com/CPack-DEB-depends-bug-fix-td7560635.html My use case is the following: - I have several components, each of which creating one specific .deb - I have dependencies across components (let's say python extensions depends on core). Right now if I am not mistaken, the CPACK_COMPONENT_COMP_DEPENDS is not handled with the debian packaging - The dependencies are not the same for each of the components. If the maintainer of the CPackDeb agrees, I can try to resolve this. Best, Raffi Enficiaud -- 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
I was wondering if this issue has been addressed so far. As far as I can tell from the bug report I don't think so... If it doesn't work in CMake 3.2 then it definitely wasn't. If the maintainer of the CPackDeb agrees, I can try to resolve this. Go ahead. Could you also provide some automated test cases for this? 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 16/04/15 14:55, Domen Vrankar a écrit : I was wondering if this issue has been addressed so far. As far as I can tell from the bug report I don't think so... If it doesn't work in CMake 3.2 then it definitely wasn't. I confirm this does not work with 3.2. I also would like to disable CPACK_DEBIAN_PACKAGE_SHLIBDEPS on some of the components (dpkg-shlibdeps complains right now for eg. packages containing only documentation). If the maintainer of the CPackDeb agrees, I can try to resolve this. Go ahead. Could you also provide some automated test cases for this? Sure! I assigned the issue to myself. Let's see how it goes. Best, Raffi -- 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 16/04/15 15:54, Raffi Enficiaud a écrit : Le 16/04/15 14:55, Domen Vrankar a écrit : I was wondering if this issue has been addressed so far. As far as I can tell from the bug report I don't think so... If it doesn't work in CMake 3.2 then it definitely wasn't. I confirm this does not work with 3.2. I also would like to disable CPACK_DEBIAN_PACKAGE_SHLIBDEPS on some of the components (dpkg-shlibdeps complains right now for eg. packages containing only documentation). If the maintainer of the CPackDeb agrees, I can try to resolve this. Go ahead. Could you also provide some automated test cases for this? Sure! I assigned the issue to myself. Let's see how it goes. I am right now testing the cmake 3.2 based on master. Before that I had a code running ok-kind-of with the default cmake of ubuntu 14.04 (2.8.12.2). When I create the debian with components for the two versions of cmake with the same source tree, (option CPACK_DEB_PACKAGE_COMPONENTS) - I can see the packages generated with 2.8.12.1 - I cannot see the packages generated with 3.2.20150416-g53264 - Cmake 3.2 is generating a package with the files at incorrect destinations: for the component core-dev, the files will be installed on core-dev/usr/include/xxx, while for cmake 2.8.12, the destination path is urs/include/xxx How can I have the previous behaviour with cmake 3.2? Thanks, Raffi -- 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 16/04/15 16:45, Raffi Enficiaud a écrit : Le 16/04/15 15:54, Raffi Enficiaud a écrit : Le 16/04/15 14:55, Domen Vrankar a écrit : I was wondering if this issue has been addressed so far. As far as I can tell from the bug report I don't think so... If it doesn't work in CMake 3.2 then it definitely wasn't. I confirm this does not work with 3.2. I also would like to disable CPACK_DEBIAN_PACKAGE_SHLIBDEPS on some of the components (dpkg-shlibdeps complains right now for eg. packages containing only documentation). If the maintainer of the CPackDeb agrees, I can try to resolve this. Go ahead. Could you also provide some automated test cases for this? Sure! I assigned the issue to myself. Let's see how it goes. I am right now testing the cmake 3.2 based on master. Before that I had a code running ok-kind-of with the default cmake of ubuntu 14.04 (2.8.12.2). When I create the debian with components for the two versions of cmake with the same source tree, (option CPACK_DEB_PACKAGE_COMPONENTS) - I can see the packages generated with 2.8.12.1 - I cannot see the packages generated with 3.2.20150416-g53264 - Cmake 3.2 is generating a package with the files at incorrect destinations: for the component core-dev, the files will be installed on core-dev/usr/include/xxx, while for cmake 2.8.12, the destination path is urs/include/xxx How can I have the previous behaviour with cmake 3.2? Thanks, Raffi Ok, it was a good excercise to start with. In the member function cmCPackGenerator::WantsComponentInstallation, apparently it is required that groups AND components exist to have the component install: https://github.com/Kitware/CMake/blob/master/Source/CPack/cmCPackGenerator.cxx#L1505 If I change the line to (!(this-ComponentGroups.empty()) || !(this-Components.empty( it works as before (cmake 2.8.12). Is it required that groups and components are defined to be able to have a component installation? (one file per component). In the wiki page, http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack I can read A component does not have to belong to any component GROUP. I checked the tests for that, and I think they do not cover that case since the groups are defined there. Any suggestions? Best, Raffi -- 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
I confirm this does not work with 3.2. I also would like to disable CPACK_DEBIAN_PACKAGE_SHLIBDEPS on some of the components (dpkg-shlibdeps complains right now for eg. packages containing only documentation). Fine with me as long as you provide the tests. Ok, it was a good excercise to start with. In the member function cmCPackGenerator::WantsComponentInstallation, apparently it is required that groups AND components exist to have the component install: https://github.com/Kitware/CMake/blob/master/Source/CPack/cmCPackGenerator.cxx#L1505 If I change the line to (!(this-ComponentGroups.empty()) || !(this-Components.empty( it works as before (cmake 2.8.12). Is it required that groups and components are defined to be able to have a component installation? (one file per component). In the wiki page, http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack This was my patch that handles the case of only one component. Somehow managed to simplify the line too much... RunCMake.CPackRPM tests this feature implicitly - creates a rpm package even though only one component is present. Do you have git permissions to push this patch? You can also send the patch and I'll commit the fix. 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
On 04/16/2015 04:19 PM, Domen Vrankar wrote: I've pushed the patch with minor changes to next. http://www.cmake.org/gitweb?p=cmake.git;h=0779b679 Thanks. The fixup! mark is useful only during incremental development of an open topic. Once a commit is in 'master' then it should be explicitly referenced by a later fixup commit with a normal commit message. I've revised the commit as: CPack: Fix single component packaging http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed0b0630 I also rebased it back on the original commit and renamed the topic to match. This makes it look like one topic that was merged to master in the middle. -Brad -- 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-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
In the member function cmCPackGenerator::WantsComponentInstallation, apparently it is required that groups AND components exist to have the component install: https://github.com/Kitware/CMake/blob/master/Source/CPack/cmCPackGenerator.cxx#L1505 If I change the line to (!(this-ComponentGroups.empty()) || !(this-Components.empty( it works as before (cmake 2.8.12). I've pushed the patch with minor changes to next. http://www.cmake.org/gitweb?p=cmake.git;h=0779b679 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-developers
[cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=11944 == Reported By:Martin Konrad Assigned To: == Project:CMake Issue ID: 11944 Category: CPack Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2011-03-09 08:29 EST Last Modified: 2011-03-09 08:29 EST == Summary:CPackDeb: Support dependencies between components/Debian packages Description: The patch provided in http://public.kitware.com/Bug/view.php?id=11655 does not transform the dependencies between CMake components into dependencies between the resulting Debian packages. == Issue History Date ModifiedUsername FieldChange == 2011-03-09 08:29 Martin Konrad New Issue == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
