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.

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?

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