Feat/cmake

[henryiii]

This is a complete CMake update, part 1 of approximately 2.

CMake 3.7 or better is now required

This enables many simplifications, and a more unified approach to targets. Many if statements dropped, though a few more added for enhanced support for later CMake versions.

Reworked C++ support to properly handle C++ version in CMake instead manually

CMake 2.8, which came out three years before 2011, does not have C++11 support (hopefully not a surprise, though given the number of people that seem to want to use a new compiler with a CMake version that significantly predates it, I'm not sure). Now it does, so PyBind11 plays nice with C++ support! FINALLY! Key points:

• PYBIND_CPP_STANDARD is deprecated, and issues a warning. It does still work, though, just grabbing the last two digits and setting CMAKE_CXX_STANDARD with it.
• If a compiler has a reasonable default (like many do now), we get to just use that, instead of injecting a flag.
• CMAKE_CXX_STANDARD is not required - CMake knows that pybind requires at least C++11 support, and will automatically add at least the C++11 flag if needed to any target that links to it (via compile features) if the compiler has a default less than C++11.
• If a target requires a higher level, that will be used instead (not duplicated, like before), either through compile features (per target) or via CMAKE_CXX_STANDARD (global) or CXX_STANDARD (per target, not inherited)
• Because it's built into CMake, it correctly supports all compilers, and correctly mixes languages (that is, it is escaped correctly for CUDA!)
• We get to remove the old caveats about setting the C++ standard before PyBind11 is used - it can be placed anywhere now.

Closes pybind#1097

If-less config files

The config file generated will not depend on the host system - this is a requirement for the CMake config files to be distributed in a pure Python wheel - which can't know what the host compiler / python version is beforehand. Generator expressions are used, which are evaluated during the build, rather than before.

Note: there are two ifs that affect the configs: If you generate with CMake 3.13+, it cannot be read by 3.7-3.12. However, this is much better than before, were you couldn't change much of anything after generating a Config file, and crucially, the 3.13+ one has a lower potential for bugs (it enforces that the dynamic lookup does not get de-duplicated accidentally). The main planned user of this feature is PyPI package, and there should be no problem getting CMake 3.13+ using pip.

Key first step for pybind#2266!

SYSTEM changes

The current handling of SYSTEM is not consistent with CMake standards. CMake treats all IMPORTED targets as SYSTEM, so this was/is always on when using configuration mode.Tthis now treats Python always as SYSTEM (may fix the warning we struggled with for a while), and treats PyBind11 as SYSTEM when being used as a subdirectory, so the SYSTEM argument to pybind11_add_module is no longer needed and is inconsistent with target_link_libraries. A warning is printed if given. You can always set NO_SYSTEM_FROM_IMPORTED if you want to make imported targets non-system.

Smaller features

• The library prints the CMake version when used as a master project. It also no longer unconditionally prints the PyBind11 version when included as a submodule.
• CMake polices are set to the newest version available, reducing warnings and hack-arounds
  • I'm supporting the built-in, modified CMake 3.11 that shipped in some versions of MSVC instead of using the native syntax for supporting a version range.
  • Closes link time optimization disabled due to OLD behaviour of CMake policy 0069 pybind/pybind11#1903
• The version number is now a standard CMake VERSION - this has the downside that it must be made up of valid numbers
  • Adding a new dev flag
  • Available as pybind11_VERSION* and PROJECT_VERSION*(, picked up correctly by CMake wherever it's needed (for example, by CPack)
• The standard BUILD_TESTING flag is now supported, along with PYBIND11_TEST
  • Both have distinct uses unless you remove building tests when this is not the master project, which is not a bad idea IMO
  • I didn't use include(CTest) here, which sets BUILD_TESTING up for you, but I could.
• The visibility=hidden flag attempt has been removed from the pybind11::module target; it caused issues (closes pybind11 incorrectly adds "-fvisibility" flag to nvcc pybind/pybind11#1710, combined with flto change closes CXX flags passed to nvcc using CMake make compilation fail pybind/pybind11#1991), it went against the description (simplest possible flags), it clashes with the correct way to do this in the pybind11_add_module function, and is better handled by a nice example (added to the docs).
• flto now uses CMake instead of custom flag checking for CMake 3.9+, closes CXX flags passed to nvcc using CMake make compilation fail pybind/pybind11#1991, partially CMake 3.12+ Python Find Routines, IPO/LTO pybind/pybind11#2201 - added PYPBIND11_CLASSIC_LTO to force the old search method and manual flags
• Python 2.7 warning suppression added to targets (I could be talked out of that one, but it nicely fixes the issues we were having at the target level - the new SYSTEM handling might have fixed it too, though)
• Moved the version macros up to the top of the detail/config file to make them easier to find and update
• Don't override additional versions if set, closes Pybind fails to build with MSVC 19.16 in C++17 mode pybind/pybind11#2089
• Building against a debug Python should work now, closes Debug build does not set -DPy_DEBUG with cmake pybind/pybind11#2018
• Targets are always installed when everything else is installed, closes Missing file pybind11Targets.cmake? pybind/pybind11#1733
• Spacing changed to 4-space indent, 2-space keyword that I've seen used a bit and like, but maybe 2-space is more standard? I usually use 4 space everywhere, but the CMake docs does use 2-space (just checked)

This has gotten large enough, so I'll be working on new FindPython support in the next PR. Also, we currently might be a bit sloppy about putting build produces in the source tree - I'll investigate that in the near future, too. This also should enable CMake configs in the python wheel, which when mixed with PEP 518 builds and scikit-build, could make something truly beautiful. :)

As a further test, I dropped this into boost-histogram (CMake mode) and awkward1 (both submodule systems) and verified that no changes were needed, it is backward compatible and still builds correctly locally.