On 08/16/2016 10:15 AM, Stuermer, Michael SP/HZA-ZSEP wrote:
After having look at the code for some minutes I remember why patching the ref instead oft he feature was my way to go:
The feature is written to file in
cmWIXFeaturesSourceWriter::EmitFeatureForComponent(), where I do not have any
patch information available. This means I'd have to change the signature of
both EmitFeatureForComponent and EmitFeatureForComponentGroup and pass a
reference to the patch instance along. Multiple occurrence of IDs can happen,
but the patch will only be applied once because applied fragments are erased
immediately after writing them to the stream.
So after all for me this was a consideration of a 1-line change vs. changing
class interfaces an passing object instances to where it might not be desirable.
There is precedence in cmWIXFilesSourceWriter::EmitComponentFile() so I
think such an interface change would be fine.
I agree the commit message of the patch is not accurate enough and if there is
way to add custom WIX-components to features without changing the cpack source
I'd be happy to do so. But so far I tried several approaches and neither worked
(see below).
This would not be any more convenient but would certainly match
expectations and be less ill defined.
e.g. when I specify a patch for a Feature I expect that the Feature with the
given ID gets patched.
Arguments against patching a FeatureRef instead are:
- There can be n FeatureRef elements for any Feature element in which case
it would not be obvious if the patch should be applied to one
(which?) or all of these
The way the patch was implemented only the featurerefs in the generated
features.wxs file would be patched and there should not be any double
occurences of a feature ref.
- While similar FeatureRef and Feature don't take the same Child elements
Right, and if both Feature and FeatureRef would be patchable we would be in trouble. For
the lazy one: this is not the case at the moment so we would not need to worry about it
(but it's very nice). For the correct one: We could introduce another attribute to
CPackWixFragment called "Type" where type of the XML node to be patched could
be stored. But this would introduce additional complexity to the cmWIXPatch class...
There is no use case to be able to patch both FeatureRef and Feature
elements when Feature elements can be patched directly.
- You can already define your own FeatureRef elements (referencing any of
the pre-existing Feature elements if wanted) without having to use the
patch mechanism
I tried this like this (in a separate additional .wxs source file added with
CPACK_WIX_EXTRA_SOURCES):
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi";>
<Fragment>
<Component Id="SetRegistryValues" Guid="@random_guid@"
Directory="INSTALL_ROOT">
<RegistryKey Root="HKLM" Key="@regkey@">
<RegistryValue Type="integer" Name="@name@" Value="@val@" />
</RegistryKey>
</Component>
<FeatureRef Id="@feature_id_from_features.wxs@" IgnoreParent="yes">
<ComponentRef Id="SetRegistryValues" />
</FeatureRef>
</Fragment>
</Wix>
Did not work, the registry value was not set. Using the proposed approach it worked. Do I have to reference it somehow different?
The linker only includes object files which provide a symbol that is
required by an object already included.
Your source file has a single symbol for the Component
"SetRegistryValues" but that symbol (I assume) is not required by any of
the other objects which the linker includes.
You could e.g. add the FeatureRef to a custom WIX.template.in (which has
the main entry point and is therefor always included),
or supply a patch for the Product element (#PRODUCT),
or create any kind of valid reference to your custom source file (if any
reference is resolved through your custom source the entire object gets
included).
Nils
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
