[cmake-developers] [Patch 5/5] Improved WIX support

Nils Gladitz nilsgladitz at gmail.com
Tue Aug 16 04:54:27 EDT 2016


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


More information about the cmake-developers mailing list