[CMake] WIX installer fails for shared files

[Mark Stijnman]

On Tue, Nov 10, 2015 at 9:22 AM, Nils Gladitz <nilsgladitz at gmail.com> wrote:

> On 11/09/2015 08:29 PM, Mark Stijnman wrote:
>
> I think there should be a change in the CMake/CPack behavior here,
> regardless of whether the WiX generator will be extended to support this
> use case. For generators that support the same file to be installed from
> more than one component, such as the archive generators, it should check if
> the files are the same, and if not, report an error. Generators that don't
> support two files with the same destination at all should give an error
> when that occurs.
>
>
> The installation (staging) logic is out of scope for CPack itself (CPack
> and CMake are distinct entities; CPack can be used without CMake) and
> within CMake it probably won't work either...
>
> CMake allows the installation to replace pre-existing files and tries to
> do so efficiently by using timestamp comparisons and omitting the operation
> if the source is not in fact newer than the destination.
> Even though this logic is not required when invoked through CPack (the
> staging area always starts out empty) it is still there.
> So replacing an existing file (which may have distinct content from the
> source) is expected and legal and actually comparing content is probably
> considered too expensive either way.
>
> I understand, but this check for files with the same destination could
(and IMHO should) still be done during the CPack generator stage.


> In the WIX generator I suppose I could perhaps detect reused destination
> paths (in distinct components) and reuse references but I am not sure I
> like the idea of actually doing file content comparisons (though in this
> case it would be much more selective than doing it for the install step).
>
That's what I've been thinking could be done, yes, but maybe it's not
needed if dependencies would work (and definitely not needed if we simply
not allow this situation at all, see below).


> Also this behavior would be specific to the WIX generator and would likely
> break semantically with every other generator.
>

Not every generator: at least the archive generators already allow this.
But this is why I'm advocating to rigorously define (and enforce) the
semantics of this situation for all CPack generators.

However, I've just found that in
https://cmake.org/Wiki/CMake:Component_Install_With_CPack, it says, under
rules for components: "1. An object cannot belong to several COMPONENT" -
so I guess it's already defined, just not enforced, leading to unspecified
behavior. I think either all generators should enforce this rule (at the
risk of breaking projects that depend on unspecified behavior) or rule 1
should be relaxed (in which case I'd like the WiX generator to support the
relaxed rule). I think I'll file this as a separate issue report (not
specific to the WiX generator).


> I wonder if I could perhaps instead do this automagically by merging
> hidden dependee components into their dependers.
>
> If you still think this is a good idea and something you would intend to
> use please open an issue.
>
> Nils
>
I think WiX generator support for CPACK_COMPONENT_${COMPNAME}_DEPENDS would
be good to have, regardless of what happens with the "two files with same
destination" issue. I'll file an issue report for this. Thanks,

best regards Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20151110/f50486b6/attachment.html>