MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006835CMakeCPackpublic2008-04-17 04:522008-07-29 10:18
ReporterYuri 
Assigned ToDavid Cole 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionduplicate 
PlatformOSOS Version
Product VersionCMake-2-6 
Target VersionFixed in VersionCMake-2-6 
Summary0006835: Multi-component packaging support
DescriptionIt is very convenient to split big source tree into several components (ex. one component per library + devel package per library, etc) and make multiple packages from different components. I found one solution how CPack could help me:
0) Use CPack in form of "cpack --config <config name>"
1) Write CMakeLists.txt as usual but with necessary components support (in INSTALL commands).
2) Write custom CPack configuration file (mypackage.cmake) in form of:
set(MYPACKAGE_COMPONENTS
    component1
    component2
    )

set(CPACK_INSTALL_CMAKE_PROJECTS)
foreach(component ${MYPACKAGE_COMPONENTS})
    list(APPEND CPACK_INSTALL_CMAKE_PROJECTS ".;MyProject;${component};/")
endforeach(component)

And the rest of options form example (http://www.cmake.org/Wiki/CMake:Packaging_With_CPack#Using_CPack_without_CMake [^])
3) Create package by executing from build directory "cpack --config mypackage.cmake"

This seems almost as hack, but can help achieving goal: Encapsulate package contents in single place without need to write custom rules for each platform-specific packager (rpm, PackageMaker, wix).

The main drawback of this approach is that make preinstall (which scans build tree) called big number of times (in simplest package I have 60 components). And installing takes a lot of time.

One of possible solutions is to specify multiple components (ex separated with comma) in CPACK_INSTALL_CMAKE_PROJECTS quadruplet.

Other approach is to introduce multi-package support for cpack. For example, rpm when building several packages from single .spec file can gracefully handle cases when same file mentioned in different rpms, and is able to install them both in the same time without conflicts.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
duplicate of 0006847closed Bill Hoffman CPack installers should allow users to select different components to install 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2008-04-17 04:52YuriNew Issue
2008-06-12 10:34Dieter RoschNote Added: 0012328
2008-06-17 13:38David ColeRelationship addedduplicate of 0006847
2008-06-17 13:38David ColeDuplicate ID0 => 6847
2008-06-17 13:38David ColeStatusnew => resolved
2008-06-17 13:38David ColeResolutionopen => fixed
2008-06-17 13:38David ColeAssigned To => David Cole
2008-06-17 13:38David ColeNote Added: 0012370
2008-06-18 04:25YuriStatusresolved => feedback
2008-06-18 04:25YuriResolutionfixed => reopened
2008-06-18 04:25YuriNote Added: 0012391
2008-06-18 04:25YuriNote Edited: 0012391
2008-06-18 05:44Dieter RoschNote Added: 0012392
2008-06-18 07:35YuriNote Added: 0012394
2008-06-18 08:24Dieter RoschNote Added: 0012395
2008-06-18 15:20Dieter RoschNote Edited: 0012395
2008-06-18 15:22Dieter RoschNote Added: 0012408
2008-07-29 03:34YuriNote Added: 0012849
2008-07-29 10:18David ColeStatusfeedback => closed
2008-07-29 10:18David ColeNote Added: 0012855
2008-07-29 10:18David ColeResolutionreopened => duplicate
2008-07-29 10:18David ColeFixed in Version => CMake-2-6

Notes
(0012328)
Dieter Rosch   
2008-06-12 10:34   
I have a similar requirement.

In our system we can drop a full release, or a "patch" (partial) release. For example, if we have 3 executables, EXE1, EXE2 and EXE3, we will drop a full release comprising EXE1, EXE2 and EXE3. If only EXE3 changes, we will do a patch release containing only EXE3.

Currently CMake seems to require the INSTALL() command in the same directory as the target being installed. If this constraint was removed, one could create a file called ReleasePatchXXX.cmake, where XXX could be your version number for example. Eg, ReleasePatch_FULL.cmake could look like this:
install(TARGETS EXE1 RUNTIME DESTINATION bin)
install(TARGETS EXE2 RUNTIME DESTINATION bin)
install(TARGETS EXE3 RUNTIME DESTINATION bin)

for the full release.

Or ReleasePatch_PATCH.cmake could look like this:
install(TARGETS EXE3 RUNTIME DESTINATION bin)

This way a developer has full-control over which targets, files etc. are included in a specific package.
(0012370)
David Cole   
2008-06-17 13:38   
See resolution and notes of duplicate issue 0006847 - does that solution work for this issue...? If that solution is not satisfactory, feel free to re-open this issue and attach a note explaining what additional features you would like to see over and above the CPack component/group approach.
(0012391)
Yuri   
2008-06-18 04:25   
It's a good patch and I suppose to adopt it to my needs, but my original problem is slightly different. As I wrote to mailing list, I have a big project with about 100 targets (I know, KDE is bigger, but we have much common :)). Most of them are libraries and plugins (plugin is a library + some manifest).
I have a requirement to make different packages (core libraries + separate devel package, basic server daemon, several sets of plugins for it, etc.), where the same library may be in multiple libraries. The most obvious solution is to assign each library, binary or plugin a separate component. This approach is similar to one used in WiX, where "component is the atomic unit of things to be installed". Next, goes "feature" term, which comprises some set of components to be installed.
Doug partly introduced this term, but only for packaging, after everything is installed.
So, I'm missing some kind of "feature" or "package" in CMake. I can even try to implement this, but I need help to elaborate conception.
(0012392)
Dieter Rosch   
2008-06-18 05:44   
My requirement is also slightly different, in that I require the ability on UNIX (ie rpm, deb, stgz, or whatever) as well, and I do not require the ability to let the user select certain components. At package build time I want to specify the libs and exe's to include in the release (in a central file or location). They should all be included and then all installed when the package is deployed.
(0012394)
Yuri   
2008-06-18 07:35   
Dieter, I'm also concerned about Linux too. The WiX/MSI was given as example of system which has 2-level components division.
Theoretically, this could be achieved in CMake now:
in EXE1 subdir:
install(TARGETS EXE1 RUNTIME DESTINATION bin COMPONENT FULL)
in EXE2 subdir:
install(TARGETS EXE2 RUNTIME DESTINATION bin COMPONENT FULL)
in EXE3 subdir:
install(TARGETS EXE3 RUNTIME DESTINATION bin COMPONENT FULL)
install(TARGETS EXE3 RUNTIME DESTINATION bin COMPONENT Patch)

(That is specify install command twice)
Note, that I didn't check that it works, but I hope it does :).

And next create 2 configuration files for CPack one for FULL component and second for Patch component.

The drawback of this approach: for each packaging type you should duplicate install command for each artifact to be installed.
(0012395)
Dieter Rosch   
2008-06-18 08:24   
(edited on: 2008-06-18 15:20)
If the double INSTALL does work (I'll check ...) that will allow some interesting ideas. If one can have the INSTALL() command in a different CMakeLists.txt than the one in which the executable/library is added, it would allow one to specify which components make up a patch, by using single CMake file.

UPDATE:
Yes! The double install() call does indeed work! As I said above, if the constraint is removed that the install() call needs to be in the same CMakeLists.txt as the target, this solution would be ideal for me.
(0012408)
Dieter Rosch   
2008-06-18 15:22   
Sorry, not sure if editing my response above triggers an email to everyone watching this thread:

Yes! The double install() call does indeed work! As I said above, if the constraint is removed that the install() call needs to be in the same CMakeLists.txt as the target, this solution would be ideal for me.

PS. Thanks for the tip!
(0012849)
Yuri   
2008-07-29 03:34   
While looking into implementation of components support, I've found an interesting thing: With component-based installation, you can install arbitrary set of components. For example:

set(CPACK_INSTALL_CMAKE_PROJECTS ".;MyProject;ALL;/")
set(CPACK_COMPONENTS_ALL Devel Schema)

So... components are designed for cpack, and regular "make install" doesn't support components at all. Therefore it is OK that code which handles complex installation/packaging solutions lives in cpack (I mean groups of components). My problem can be solved in terms of issue 0006847 and you can close this bug.
(0012855)
David Cole   
2008-07-29 10:18   
Closing (again) in response to the notes added since the last time this issue was closed. See also notes in "duplicate" issue 0006847.