[CMake] CPACK_COMPONENT_<compName>_DEPENDS doesn't work

Wed Nov 27 02:12:24 EST 2013

2013/11/27  <jeff at linuxwest.com>:
> What an honor for me that you guys responded so quickly. Our group has done
> well to move to CMake. Sorry for taking such a long time to reply; I'm part
> of a big organization that can be slow to decide things.
>
> The way this is going, is to continue with one package rather than use a
> workaround, if we have some idea if/when CPACK_COMPONENT_<compName>_DEPENDS
> will be implemented. But, am I understanding correctly that
> CPACK_COMPONENT_<compName>_DEPENDS isn't expected to work? I see some CMake
> examples that use it so I'm confused why this works for some people.

Probably because htey mostly use single file package generator, which
is may be componentize, but keep reading.

> I guess my question now is, is there a plan to make the
> CPACK_COMPONENT_<compName>_DEPENDS mechanism work? At the risk of being
> asked to contribute :), is there any way to know when? My group can make a
> decision based on that info.

The CPack component thing was designed for package generator (like
NSIS) for which all component
are put in the very same installer. So specifying
"CPACK_COMPONENT_<compName>_DEPENDS" is easy
in that case, this var may only contains the name of other components
from the package you are currently building.

Now if am not mistaken you expect this var to contain the
specification of "external" [to your project] dependency
AND make it work for let's say ZIP, NSIS, WiX, RPM and DEB right?

Now back to COMPONENT to INSTALLER file mapping.
You shoudl know that there is potentially 3 kinds of CPack generator:

1) the one which are NOT COMPONENT-aware and always generate a single
MONOLITHIC to-be-installed file package
2) the one which ARE COMPONENT-aware but still generate single
to-be-installed file package, e.g. NSIS (and soon WiX)
3) the one which ARE COMPONENT-aware and may generate various number
of packages depending on the value
    of CPACK_COMPONENTS_GROUPING

Read that page for a possibly more detailed overbiew:
http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack

So in the end Yes "CPACK_COMPONENT_<compName>_DEPENDS" works in many cases
No there is no work going on to support unified usage of that for the
3 kinds of previously decribed packaging scheme
AND for specifying external deps.

There are some work for handling dependences for DEB and RPM pending,
I'll dig up de bug tracker
and give you references.

There are currently paused because they mostly depend on more
flexiible naming scheme for multi-file CPack generators
see: http://public.kitware.com/Bug/view.php?id=12997

And yes contribution are more than welcome!!

>
> Thank you greatly!
> Jeff
>
> <turkey here>
>
> On Wed Nov 20 4:09 , Jeremy Fix sent:
>
> On 11/20/2013 09:52 AM, Eric Noulard wrote:
>> 2013/11/20 Jeremy Fix <Jeremy.Fix at supelec.fr>:
>>> Hello,
>>>
>>> I'm surprised CPACK_RPM_gui_PACKAGE_REQUIRES works , I don't find any use
>>> of
>>> CPACK_RPM__REQUIRES in CPackRPM.cmake;
>
>>
>> Yes there is for all
>>
>> URL REQUIRES SUGGESTS PROVIDES OBSOLETES PREFIX CONFLICTS AUTOPROV
>> AUTOREQ AUTOREQPROV
>>
>> see lines 555 and following we check for component specific value first:
>>
>> if(DEFINED
>> CPACK_RPM_${CPACK_RPM_PACKAGE_COMPONENT}_PACKAGE_${_RPM_SPEC_HEADER})
>>
>> then
>> else()
>> if(DEFINED CPACK_RPM_PACKAGE_${_RPM_SPEC_HEADER})
>>
>> However we may have check the definition of
>> "CPACK_COMPONENT__DEPENDS" first
>> in order to fill-in CPACK_RPM__REQUIRES.
>
>> This is not done.
>>
>> Moreover I'm not sure this could be easily factoired out since the
>> syntax for dependency specification
>> may well be package type specific (different name or syntax for DEB or
>> RPM for example).
>>
>>> What I can suggest you for generating several packages with different
>>> dependencies is to generate the different packages in multiple steps. If
>>> we
>>> suppose you defined 2 components (in the INSTALL commands) called :
>>> binary
>>> and devel ,you can then generate the packages (whether deb or rpm) as
>>> follows:
>>>
>>>
>>> SET(CPACK_INSTALL_CMAKE_PROJECTS
>>> "${CMAKE_BINARY_DIR};${CMAKE_PROJECT_NAME};
>>> ${MYBUILDTYPE};/")
>>>
>>> then for the dependencies:
>>>
>>> IF(MYBUILDTYPE STREQUAL "binary")
>>> SET(CPACK_RPM_PACKAGE_REQUIRES "gsl")
>>> SET(CPACK_DEBIAN_PACKAGE_DEPENDS "libgsl0-dev")
>>> ELSE()
>>> SET(CPACK_RPM_PACKAGE_REQUIRES "gsl-devel")
>>> SET(CPACK_DEBIAN_PACKAGE_DEPENDS "libgsl0-dev")
>>> ENDIF()
>>>
>>>
>>> Then the packages are generated with:
>>>
>>> cmake -DMYBUILDTYPE="binary" && make package
>>> cmake -DMYBUILDTYPE="devel" && make package
>>
>> You should be able to do that with component packaging and a
>> CPACK_PROJECT_CONFIG_FILE.
>>
>
> I'm not familiar with CPACK_PROJECT_CONFIG_FILE;
>
> I had issues with the package names generated with component packaging
> as the component name is added at the end of the package name; I
> prefered to generate the components in two steps to tweak the
> CPACK_RPM_PACKAGE_NAME and I use some commands a bit more complicated
> than the above;
>
> IF(MYBUILDTYPE STREQUAL "binary")
> SET(CPACK_RPM_PACKAGE_NAME ${CMAKE_PROJECT_NAME})
> SET(CPACK_DEBIAN_PACKAGE_NAME ${CMAKE_PROJECT_NAME})
> SET(CPACK_PACKAGE_FILE_NAME
> ${CMAKE_PROJECT_NAME}-${PACKAGE_VERSION}-${CMAKE_SYSTEM_PROCESSOR})
> SET(CPACK_INSTALL_CMAKE_PROJECTS
> "${CMAKE_BINARY_DIR};${CMAKE_PROJECT_NAME};binary;/")
> ELSEIF(MYBUILDTYPE STREQUAL "devel")
> SET(CPACK_RPM_PACKAGE_NAME ${CMAKE_PROJECT_NAME}-devel)
> SET(CPACK_DEBIAN_PACKAGE_NAME ${CMAKE_PROJECT_NAME}-devel)
> SET(CPACK_PACKAGE_FILE_NAME
> ${CMAKE_PROJECT_NAME}-devel-${PACKAGE_VERSION}-${CMAKE_SYSTEM_PROCESSOR})
> SET(CPACK_INSTALL_CMAKE_PROJECTS
> "${CMAKE_BINARY_DIR};${CMAKE_PROJECT_NAME}-devel;devel;/")
> ENDIF()
>
>
> This is just to ensure consistency between the field "Name:" in the
> autogenerated spec file is : pkg and pkg-devel ;
> and the generated RPM (or deb) filenames: pkg-1.00-i686.rpm and
> pkg-devel-1.00-i686.rpm
>
>
> jeremy.
>
>
>
> --
>
> 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://www.cmake.org/mailman/listinfo/cmake
>
>
>
> --
>
> 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://www.cmake.org/mailman/listinfo/cmake

-- 
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org