Chuck Atkins via llvm-dev
2016-Apr-27 19:01 UTC
[llvm-dev] [cfe-dev] Fwd: Raising CMake minimum version to 3.4.3
> > 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/llvm-dev/attachments/20160427/23f42670/attachment.html>
Chris Bieneman via llvm-dev
2016-Apr-27 19:09 UTC
[llvm-dev] [cfe-dev] Fwd: Raising CMake minimum version to 3.4.3
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/llvm-dev/attachments/20160427/9099b724/attachment.html>
Renato Golin via llvm-dev
2016-Apr-27 19:12 UTC
[llvm-dev] [cfe-dev] Fwd: Raising CMake minimum version to 3.4.3
On 27 April 2016 at 20:01, Chuck Atkins <chuck.atkins at kitware.com> wrote:> 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()This could still be dangerous if the user has a git clone. I'd rather follow what Chris said, and update CMake version's every year or two, than have to rely on multiple configuration scenarios that not everyone tests. cheers, --renato
Chuck Atkins via llvm-dev
2016-Apr-27 19:13 UTC
[llvm-dev] [cfe-dev] Fwd: Raising CMake minimum version to 3.4.3
> > 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. >Indeed that doesn't work for all situations. The extensive advancement of generator expressions is a huge leap from older CMake versions given that they had just started to really appear near the end of 2.8. You can't work around that effectively by just using a few newer CMake modules. It will, however, give you a way to keep up to date with the frequently changing ExternalProject module once updating the minimum version. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160427/6837823b/attachment.html>
Chris Bieneman via llvm-dev
2016-Apr-27 19:26 UTC
[llvm-dev] [cfe-dev] Fwd: Raising CMake minimum version to 3.4.3
> On Apr 27, 2016, at 12:13 PM, Chuck Atkins <chuck.atkins at kitware.com> wrote: > > 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. > > Indeed that doesn't work for all situations. The extensive advancement of generator expressions is a huge leap from older CMake versions given that they had just started to really appear near the end of 2.8. You can't work around that effectively by just using a few newer CMake modules. It will, however, give you a way to keep up to date with the frequently changing ExternalProject module once updating the minimum version. >Absolutely. In the future if there are changes to ExternalProject that are only in the CMake module we can have a copy in the LLVM repository to provide that compatibility. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160427/7c7ca5be/attachment.html>