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

[Stuermer, Michael SP/HZA-ZSEP]

> -----Original Message-----
> From: Nils Gladitz [mailto:nilsgladitz at gmail.com]
> Sent: Tuesday, August 16, 2016 10:54 AM
> To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers
> Subject: Re: [cmake-developers] [Patch 5/5] Improved WIX support
> 
> 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.
> 

Ok I'll do this. Should solve all issues and doubts hopefully.

> >
> > 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
... meant NOT very nice, of course ...
> 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.
> 
Right.
> >
> >> - 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).
> 

 Adding FeatureRef to #PRODUCT does not work. I get the following message:

features.wixobj : error LGHT0095 : Multiple primary references were found for Feature '@feature@' in Feature 'ProductFeature' and Product '{@guid@}'

> Nils
> .

Michael