View Issue Details [ Jump to Notes ] [ Print ]
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.
TagsNo tags attached.
Attached Files

 Relationships
duplicate of 0006847closedBill Hoffman CPack installers should allow users to select different components to install 

  Notes
(0012328)
Dieter Rosch (reporter)
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 (manager)
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 (reporter)
2008-06-18 04:25
edited on: 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 (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
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 (manager)
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.

 Issue History
Date Modified Username Field Change
2008-04-17 04:52 Yuri New Issue
2008-06-12 10:34 Dieter Rosch Note Added: 0012328
2008-06-17 13:38 David Cole Relationship added duplicate of 0006847
2008-06-17 13:38 David Cole Duplicate ID 0 => 6847
2008-06-17 13:38 David Cole Status new => resolved
2008-06-17 13:38 David Cole Resolution open => fixed
2008-06-17 13:38 David Cole Assigned To => David Cole
2008-06-17 13:38 David Cole Note Added: 0012370
2008-06-18 04:25 Yuri Status resolved => feedback
2008-06-18 04:25 Yuri Resolution fixed => reopened
2008-06-18 04:25 Yuri Note Added: 0012391
2008-06-18 04:25 Yuri Note Edited: 0012391
2008-06-18 05:44 Dieter Rosch Note Added: 0012392
2008-06-18 07:35 Yuri Note Added: 0012394
2008-06-18 08:24 Dieter Rosch Note Added: 0012395
2008-06-18 15:20 Dieter Rosch Note Edited: 0012395
2008-06-18 15:22 Dieter Rosch Note Added: 0012408
2008-07-29 03:34 Yuri Note Added: 0012849
2008-07-29 10:18 David Cole Status feedback => closed
2008-07-29 10:18 David Cole Note Added: 0012855
2008-07-29 10:18 David Cole Resolution reopened => duplicate
2008-07-29 10:18 David Cole Fixed in Version => CMake-2-6

Copyright © 2000 - 2018 MantisBT Team