MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0012062CMakeCPackpublic2011-04-09 03:482016-01-04 11:52
ReporterEric NOULARD 
Assigned ToDomen Vrankar 
PrioritynormalSeverityfeatureReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformLinuxOSDebian-basedOS Version
Product VersionCMake 2.8.4 
Target VersionFixed in VersionCMake 3.4 
Summary0012062: CPackDeb: The EXTRA control files may not be specified on a per-component basis
DescriptionCPACK_DEBIAN_PACKAGE_CONTROL_EXTRA may be used to add user specified
control file to the .deb.
Currently one cannot specify a component specific Control file.


# CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA
# This variable allow advanced user to add custom script to the control.tar.gz (inside the .deb archive)
# Typical examples are:
# - conffiles
# - postinst
# - postrm
# - prerm"
# Usage:
# SET(CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA
# "${CMAKE_CURRENT_SOURCE_DIR/prerm;${CMAKE_CURRENT_SOURCE_DIR}/postrm")
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0012061closed Eric NOULARD CPackDeb fails if using components and CONTROL_EXTRA 
related to 0012063closed Eric NOULARD CPackRPM: cannot specify per-component install scripts 
related to 0013231closed Raffi Enficiaud CPackDeb incorrectly "leaks" Debian dependencies across components 
Attached Filespatch 0001-Make-deb-package-options-configurable-per-component.patch (5,362) 2012-05-23 05:24
https://public.kitware.com/Bug/file/4335/0001-Make-deb-package-options-configurable-per-component.patch
Issue History
Date ModifiedUsernameFieldChange
2011-04-09 03:48Eric NOULARDNew Issue
2011-04-09 03:50Eric NOULARDRelationship addedrelated to 0012061
2011-04-09 03:51Eric NOULARDNote Added: 0026156
2011-04-09 03:54Eric NOULARDRelationship addedrelated to 0012063
2012-05-23 05:24Mika FischerFile Added: 0001-Make-deb-package-options-configurable-per-component.patch
2012-05-23 05:26Mika FischerNote Added: 0029548
2012-05-23 05:29Eric NOULARDNote Edited: 0029548bug_revision_view_page.php?bugnote_id=29548#r660
2012-05-23 05:29Eric NOULARDRelationship addedrelated to 0013231
2012-05-23 17:02Eric NOULARDAssigned To => Eric NOULARD
2012-05-23 17:02Eric NOULARDStatusnew => assigned
2012-05-23 18:23Eric NOULARDNote Added: 0029550
2012-05-24 08:24Mika FischerNote Added: 0029555
2012-05-24 09:23Eric NOULARDNote Added: 0029556
2012-05-24 09:25Eric NOULARDNote Added: 0029557
2015-07-13 10:07Nils GladitzAssigned ToEric NOULARD => Domen Vrankar
2015-08-07 05:29Domen VrankarNote Added: 0039252
2015-08-07 05:29Domen VrankarStatusassigned => resolved
2015-08-07 05:29Domen VrankarFixed in Version => CMake 3.4
2015-08-07 05:29Domen VrankarResolutionopen => fixed
2016-01-04 11:52Robert MaynardNote Added: 0040108
2016-01-04 11:52Robert MaynardStatusresolved => closed

Notes
(0026156)
Eric NOULARD   
2011-04-09 03:51   
The issue has been raised in 0012061.
A similar issue has been raised for RPM on the ML:

http://www.cmake.org/pipermail/cmake/2011-March/043393.html [^]
(0029548)
Mika Fischer   
2012-05-23 05:26   
(edited on: 2012-05-23 05:29)
I've attached a patch against current master, that fixes this issue and probably also 0013231.

Please review it and let me know if changes are needed.
(0029550)
Eric NOULARD   
2012-05-23 18:23   
Hi Mika,

Thank you for the patch.
The idea is ok but teh current patch generates more "leaks" problems
(and doesn't solve 0012321).

When you do:
IF(CPACK_DEB_PACKAGE_COMPONENT AND CPACK_DEBIAN_PACKAGE_${CPACK_DEB_PACKAGE_COMPONENT}_CONTROL_EXTRA)
  SET(CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA "${CPACK_DEBIAN_PACKAGE_${CPACK_DEB_PACKAGE_COMPONENT}_CONTROL_EXTRA}")
ENDIF(CPACK_DEB_PACKAGE_COMPONENT AND CPACK_DEBIAN_PACKAGE_${CPACK_DEB_PACKAGE_COMPONENT}_CONTROL_EXTRA)

you reset CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA for the concerned component
if CPACK_DEBIAN_PACKAGE_FIRSTCOMP_CONTROL_EXTRA is defined.
but you make it leak to the possible next component even if

neither CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA or
CPACK_DEBIAN_PACKAGE_NEXTCOMP_CONTROL_EXTRA is defined.

the proper algorithm for a component aware options should be:

1) check if non component is defined and if not already saved
    "save it"
   set(CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA_GLOBAL ${CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA})
   if it does not exists then
   set(CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA_GLOBAL "")

2) set(CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA ...) to
    
   2a) component specific value if it exists
   2b) previously saved global value if component specific does not exists
         --> this may reset value to nothing if a previous
             component did provide a specific value and and initial global
             value did not exist.


May be this could be done in a macro for any var since it's rather painful
to write for every possible component specific var.
(0029555)
Mika Fischer   
2012-05-24 08:24   
Hi Eric,

thanks for the comments. I'm quite unclear as to how the process of CPack works. I had assumed that CPackDeb.cmake is called once for each component with a fresh state.

Since that's not the case, I'll change it to the method you suggested.
(0029556)
Eric NOULARD   
2012-05-24 09:23   
Hi Mika,
CPack<GEN>.cmake script namely CPackRPM.cmake, CPackDEB.rpm
are called by the specific C++ CPack Generator (cmCPackDebGenerator.cxx)
in a "CMake script context" which has been prepared by the
generic C++ CPack Generator (cmCPackGenerator.cxx).

In fact this is kind of bidirectional communication.

1) cmCPackGenerator sets up some CPACK_xxx var (beginning with CPackConfig.cmake)
2) cmCPack<GEN>Generator then add its generator specific CPACK_<GEN>_xxx value
plus may be some [specific] change in CPACK_xxx.
then for each component:
3) the CPack<GEN>.cmake script is called
4) cmCPack<GEN>Generator finalize the component package possibly
   getting values set from within CPack<GEN>.cmake

Not all CPack generators work this way, and some of them are entirely
done in the C++ part (CPack archive generators (ZIP, TGZ, etc...).
CPackRPM and CPackDEB work this way.

So the CMake script context seen by CPack<GEN>.cmake
may be partly inherited from one component to another.

But you are right it would have been easier to avoid that inheritance.
It may be possible to reset the context to the one given by
the common part.

We could even use CMake functions inside CPack<GEN>.cmake since
variable set inside function are "scoped".

It may be the best (most simple) approach.
(0029557)
Eric NOULARD   
2012-05-24 09:25   
Last thought,
the problem with the function approach it's that it cannot
be used everywhere because the C++ part of the generator expect
some var to be defined by the CPack<GEN>.cmake script.
(0039252)
Domen Vrankar   
2015-08-07 05:29   
Added CPACK_DEBIAN_<COMPONENT>_PACKAGE_CONTROL_EXTRA variable that adds per component functionality.

Commit:
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=3e6b2ab6832f77a7e073b55331352a88a5d28488 [^]
(0040108)
Robert Maynard   
2016-01-04 11:52   
Closing resolved issues that have not been updated in more than 4 months.