View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0015841CMake(No Category)public2015-11-10 10:062016-06-10 14:31
ReporterMark Stijnman 
Assigned ToNils Gladitz 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionmoved 
PlatformOSOS Version
Product VersionCMake 3.3.2 
Target VersionFixed in Version 
Summary0015841: CPack WiX generator should support component dependencies and default disabled components
DescriptionFor the common use case where multiple components depend on the same shared files (such as executables depending on DLLs), these shared components should automatically be installed when the user selects a component that depends on them, and not be installed if no depending components are selected. For that to work, the WiX generator should support the CPACK_COMPONENT_${COMPNAME}_DEPENDS and CPACK_COMPONENT_${COMPNAME}_DISABLED variables.
Steps To ReproduceSee attached file CMakeLists.txt. Run cmake and cpack to produce an installer. The installer defines 3 components, the first two of which depend on a component 'common', which is hidden and disabled by default.

The expected behavior is that 'common' is automatically installed if either 'comp1' or 'comp2' are selected, but not if only 'comp3' is selected.

The current behavior is that 'common' is always installed (which at least won't break the install due to missing dependencies).
Additional InformationImplementation suggestions:

1. Currently, each CPack component becomes a WiX Feature, and each file becomes a WiX Component, that is referenced from the feature. Dependencies can be implemented by also adding references to components from all features it depends on. Components that are installed more than once will be reference-counted. This is the standard way WiX installers deal with common files.

Downside: misses WiX components that were injected using separate fragments or patch mechanism. Also won't work with features that don't contain components at all, but for example a MergeRef (which is how I install Visual Studio C++ runtime libraries).

Variation: create a ComponentGroup for each feature, and add the component references there. This way, each feature just references its own component group, and references all component groups for featrues it depends on. This way you only have to define and emit the component list for each CPack component once. Otherwise, it has the same downsides as 1, except that it allows the user to inject WiX components in the ComponentGroup instead of in the Feature, which will make the dependencies work correctly again. (As an aside, it would be nice to have a mechanism to inject WiX Components by CPack component name, instead of by generated WiX Feature ID, which would be resilient against such implementation changes)

2. Generate a VB script file that implements a Custom Action, which reads and manipulates Session.FeatureRequestState based on the dependencies. The CA must then be inserted in the correct location of the install sequence.

Downside: seems much more complex to me.
TagsNo tags attached.
Attached Filestxt file icon CMakeLists.txt [^] (714 bytes) 2015-11-10 10:06 [Show Content]

 Relationships

  Notes
(0042885)
Kitware Robot (administrator)
2016-06-10 14:29

Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

 Issue History
Date Modified Username Field Change
2015-11-10 10:06 Mark Stijnman New Issue
2015-11-10 10:06 Mark Stijnman File Added: CMakeLists.txt
2015-11-10 10:21 Nils Gladitz Assigned To => Nils Gladitz
2015-11-10 10:21 Nils Gladitz Status new => assigned
2016-06-10 14:29 Kitware Robot Note Added: 0042885
2016-06-10 14:29 Kitware Robot Status assigned => resolved
2016-06-10 14:29 Kitware Robot Resolution open => moved
2016-06-10 14:31 Kitware Robot Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team