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-boun...@cmake.org] On Behalf Of Stephen Kelly Sent: Tuesday, September 22, 2015 4:00 PM To: cmake-developers@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 -- 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
