MantisBT - CMake
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).
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.
CMakeLists.txt (714) 2015-11-10 10:06https://public.kitware.com/Bug/file/5572/CMakeLists.txt