2013/11/27 <j...@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....@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 -- 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