[cfe-dev] [llvm-dev] Fwd: Raising CMake minimum version to 3.4.3

[Chris Bieneman via cfe-dev]

The problem I see with doing this in the current situation is that it isn’t just the CMake module we need. If you look at the changes I called out in my earlier email, there are associated CMake C++ source changes too.

I also think that one of the limitations I frequently come up against with CMake 2.8.12, is that newer CMake versions accept generator expressions in more places. This is entirely implemented in the CMake C++ code, and there is no way to workaround it in CMake scripts other than not using generator expressions.

-Chris

> On Apr 27, 2016, at 12:01 PM, Chuck Atkins <chuck.atkins at kitware.com> wrote:
> 
>  
> > Replicating ExternalProject would be a lot of work...
> 
> One approach commonly used with CMake modules that change frequently upstream is for the project to keep a local copy and have a check in place to use CMake's version if new enough.  For instance, in llvm's source tree:
> 
> cmake/modules/ExternalProject.cmake:
> if(CMAKE_VERSION VERSION_LESS "3.5.1")
>   include(${PROJECT_SOURCE_DIR}/cmake/modules/newcmake/ExternalProject.cmake)
> else()
>   include(${CMAKE_ROOT}/Modules/ExternalProject.cmake)
> endif()
> 
> cmake/modules/newcmake/ExternalProject.cmake - Copy of the ExternalProject.cmake shipped with 3.5.1
> 
> Then in the top level CMakeLists.txt, just include(ExternalProject).  It will first load the version-check sicne that's in the module path and then load CMake's copy if new enough, otherwise llvm's copy.  This way you can keep the minimum CMake version for the project at 3.4.3, but make sure that your always using ExternaProject from at least 3.5.1.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160427/9099b724/attachment.html>