[cmake-developers] Generator expressions for install destination

Robert Goulet Robert.Goulet at autodesk.com
Tue Sep 22 16:27:37 EDT 2015


Ok then perhaps the refactoring can wait but we'd still like to get install(FILES) destination genex support in 3.4 if possible, and genex evaluation requires the cmMakefile. How should we proceed then?

-----Original Message-----
From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Stephen Kelly
Sent: Tuesday, September 22, 2015 4:00 PM
To: cmake-developers at cmake.org
Subject: Re: [cmake-developers] Generator expressions for install destination

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.



-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


More information about the cmake-developers mailing list