[cmake-developers] Generator expressions for install destination
Stephen Kelly
steveire at gmail.com
Tue Sep 22 16:00:00 EDT 2015
Brad King wrote:
> On 09/22/2015 09:58 AM, Robert Goulet wrote:
>> Patch attached for adding makefile to install generators.
>> This refactoring is required for install(FILES) genex support,
>> and most likely other install() signatures in the future.
>
> Thanks. I applied that and merged to 'next' for testing:
>
> cmInstallGenerator: Add Makefile member
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d44cb327
>
> I also extended the topic with some other refactoring it enables:
>
> cmInstallFilesGenerator: Drop LocalGenerator member
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e4b1728c
>
> cmInstallTargetGenerator: Simplify using Makefile member
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3f6b267d
This is going in the wrong direction. See
(Merge topic 'generators-use-cmLocalGenerator', 2015-08-24)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9135e370
Generator expressions are evaluated at generation-time, but with
configuration-time types (cmMakefile and cmTarget). They should instead use
generation-time types (cmLocalGenerator and cmGeneratorTarget). cmMakefile
currently stores cmGeneratorTargets but it should not know them at all. This
is a layering violation.
See the fix-layering-violation branch in my clone which implements that and
also contains other orthogonal and wip refactorings for my convenience (I
have been cherry-picking commits from this into branches to merge to next):
https://github.com/steveire/CMake/commits/fix-layering-violation
None of that refactoring can proceed until after CMake 3.4 is released:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14286/focus=14323
The patch from Robert should not undo that effort, so the branch should be
reverted from next and not merged to master.
Thanks,
Steve.
More information about the cmake-developers
mailing list