[llvm-dev] Leveraging newer CMake features for Language standards

[Chuck Atkins via llvm-dev]

>
> 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>