[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