Chuck Atkins via llvm-dev
2016-Oct-20 15:49 UTC
[llvm-dev] Leveraging newer CMake features for Language standards
LLVM currently has CMake code to try to detect the various options needed to compile with C++11 support that has been around since prior to the CMake version bump. One of the nicer features that came with the newer required CMake version is that very thing. Rather than try to discern this yourself CMake has the CXX_STANDARD and CXX_STANDARD_REQUIRED target properties. If set appropriately on a given target then the approiate compiler flags for that language standard as known by CMake with be applied. You can set the global default for this by defining in teh cop level CMakeLists.txt: set(CMAKE_CXX_STANDARD 11) set(CMAKE_CXX_STANDARD_REQUIRED True) Unrelated but in a similar situation is the -fPIC flag. The POSITION_INDEPENDENT_CODE target proeprty is available, which can be initialized toa default value with: set(CMAKE_POSITION_INDEPENDENT_CODE True) What are peoples thoughts about reducing HandleLLVMOptions.cmake to factor out and leverage options that CMake already knows about and knows how to apply? I wanted to put a bit of time into this but didn't want to spin my wheels if there were major objections to idea. ---------- Chuck Atkins Staff R&D Engineer, Scientific Computing Kitware, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161020/4902f020/attachment.html>
C Bergström via llvm-dev
2016-Oct-20 16:23 UTC
[llvm-dev] Leveraging newer CMake features for Language standards
Speaking only from observation - Most likely you'll have to let the feature bake for a couple of versions until it's easily available in the main Linux distributions. What version did this become available? Is there any distro which has it available in the default repo? (Also is it available on FBSD, Win.. etc) It can't hurt to propose a bump in minimum cmake version, including the justification, but if it isn't broke - why fix it? ------------ On this feature specifically, I question how robust it will be in figuring out if c++11 or other c++ standard is *really* supported. Does it internally include some complex hello world or just check for flags available.. etc... How will TR be handled? What versions are currently supported? On Thu, Oct 20, 2016 at 11:49 PM, Chuck Atkins via llvm-dev <llvm-dev at lists.llvm.org> wrote:> LLVM currently has CMake code to try to detect the various options needed to > compile with C++11 support that has been around since prior to the CMake > version bump. One of the nicer features that came with the newer required > CMake version is that very thing. Rather than try to discern this yourself > CMake has the CXX_STANDARD and CXX_STANDARD_REQUIRED target properties. If > set appropriately on a given target then the approiate compiler flags for > that language standard as known by CMake with be applied. You can set the > global default for this by defining in teh cop level CMakeLists.txt: > > set(CMAKE_CXX_STANDARD 11) > set(CMAKE_CXX_STANDARD_REQUIRED True) > > Unrelated but in a similar situation is the -fPIC flag. The > POSITION_INDEPENDENT_CODE target proeprty is available, which can be > initialized toa default value with: > > set(CMAKE_POSITION_INDEPENDENT_CODE True) > > What are peoples thoughts about reducing HandleLLVMOptions.cmake to factor > out and leverage options that CMake already knows about and knows how to > apply? I wanted to put a bit of time into this but didn't want to spin my > wheels if there were major objections to idea. > > ---------- > Chuck Atkins > Staff R&D Engineer, Scientific Computing > Kitware, Inc. > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >
Chuck Atkins via llvm-dev
2016-Oct-20 16:58 UTC
[llvm-dev] Leveraging newer CMake features for Language standards
> > It can't hurt to propose a bump in minimum cmake version, including > the justification, but if it isn't broke - why fix it? >No need to bump cmake versions. POSITION_INDEPENDENT_CODE has been around since 2.8.12 and CXX_STANDARD has been around since 3.1. The current minimum version is 3.4 so I'm simply proposing that some of the feattures that came with the version increase a few mmonths ago start to get leveraged.> On this feature specifically, I question how robust it will be in > figuring out if c++11 or other c++ standard is *really* supported. >It's manual. In Modules/Compilers/ in the same place that a compiler's other flags are defined, i.e. what flag to pas for Include dirs, library dirs, verbose output, etc. There are also definitions for which flags to pass to a given compiler for turning on C++ 98, 11, or 14 support, or enabling language extensions. So obviously for this to work for a given compiler and version then it needs to be taught accordingly. Support should already be in place for most compilers that build LLVM, but whichever ones aren't I'm willing to add it.> Does it internally include some complex hello world or just check for > flags available.. etc... How will TR be handled? What versions are > currently supported? >As for partial standard support, that's a bit of a trickier issue. There is currently support for "compile features" where you can explicitly say "i need feature foo" where a compiler may say it supports the language spec but it's not fully implemented. Currently CMake supports the CXX_STANDARD values of 98, 11, and 14. TRs are not supports because they are not accepted language specs so if if LLVM wanted to explicitly depend on needing certiaqn TR funcitonality available in a compiler that isn't part of the language spec, then that case would need to be addressed manually. It's a. explicit table, not auto-detected, so if a current compiler doesn't have a populated feature table then that will need to be done but there's no barriers to making that happen. For language standard, see: https://cmake.org/cmake/help/v3.7/prop_tgt/CXX_STANDARD.html https://cmake.org/cmake/help/v3.7/prop_tgt/CXX_STANDARD_REQUIRED.html For compile features, see: https://cmake.org/cmake/help/v3.7/manual/cmake-compile-features.7.html https://cmake.org/cmake/help/v3.7/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html Similarly, the same is available for C89/90, 99, and 11. As for POSITION_INDEPENDENT_CODE, that's been available for a very long time in CMake and has been relied on for years. - Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161020/f0608596/attachment.html>
Apparently Analagous Threads
- [LLVMdev] llvm trunk build failed in cmake_install.cmake on ARM platform
- [LLVMdev] cmake/ninja build failing
- ARM build with v3.7-rc3 with CONFIG_XEN_GNTDEV=m
- LVM Checksum error when using persistent grants (#linux-next + stable/for-jens-3.8)
- Keys used to sign releases