[cmake-developers] [CMake 0015841]: CPack WiX generator should support component dependencies and default disabled components
Mantis Bug Tracker
mantis at public.kitware.com
Tue Nov 10 10:06:52 EST 2015
The following issue has been SUBMITTED.
======================================================================
https://public.kitware.com/Bug/view.php?id=15841
======================================================================
Reported By: Mark Stijnman
Assigned To:
======================================================================
Project: CMake
Issue ID: 15841
Category: (No Category)
Reproducibility: have not tried
Severity: minor
Priority: normal
Status: new
======================================================================
Date Submitted: 2015-11-10 10:06 EST
Last Modified: 2015-11-10 10:06 EST
======================================================================
Summary: CPack WiX generator should support component
dependencies and default disabled components
Description:
For 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 Reproduce:
See 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 Information:
Implementation 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.
======================================================================
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
======================================================================
More information about the cmake-developers
mailing list