Generalize cmake compiler support

[chuckatkins]

Related to #1381

[jagerman]

This is going to change the default flag to -std=gnu++14; aside from that it looks good.

At the moment I mildly prefer the defaults going to the stricter language version (i.e. skipping the ..._EXTENSION_COMPILE_OPTIONs), but I'm willing to listen to a compelling argument as to why they should changed.

[chuckatkins]

I get it, and I actually agree that keeping the default to use no extensions is preferred. So, really the motivation for doing it this way was to mimic CMake's behavior for language standards abstraction. In CMake >= 3.1 (which is when the language standards abstraction was first introduced), the default behavior is to have CXX extensions enabled. This was primarily to make CMake's default behavior match the default behavior of compilers that build with newer standards by default now. Most of them enable extensions by default as well. You can explicitly disable them with set(CMAKE_CXX_EXTENSIONS OFF). I'll take a shot at re-working this to leverage the language abstractions but also disable extensions.

[chuckatkins]

Not sure why this would cause the Travis failure but I'll look into it

[ax3l]

@chuckatkins CI fixed :)

[chuckatkins]

I borked these commit so let me rebase and push the correct ones...

[wjakob]

This line is potentially problematic. The version requirement for pybind11 is MSVC 2015 Update 3. I don't think it will be able to deal with C++14 mode.

[bstaletic]

MSVC 2015 Update 3 is the one that introduced /std:c++14 and /std:c++latest.

https://blogs.msdn.microsoft.com/vcblog/2016/06/07/standards-version-switches-in-the-compiler/

[wjakob]

Hm good point -- and I forgot that we're actually testing MSVC 2015 on AppVeyor.

[chuckatkins]

FWIW the MSVC behavior isn't changed in this PR from what it was before. I only inverted the if/else order to have the larger, most often followed, code block to be the if condition rather than the else.

[wjakob]

Looks good to me – @jagerman ?

[jagerman]

Looks good to me.

[chuckatkins]

ping?

[jagerman]

One more change needed before merging: the documentation for compiling should be updated to reference the newer cmake style. It's a nicer approach and is likely to fit better with other cmake projects in the future.

I have one other question: what happens if someone is using the existing PYBIND11_CPP_STANDARD and updates pybind -- does the project continue to build with the current flags? (In other words, is the CMAKE_CXX_... stuff purely opt-in and just not set if not being used?)

[wjakob]

@chuckatkins : I think this is basically ready to be merged, except for the documentation by @jagerman above. Could you please add this? Thanks!

[ax3l]

Will we ever merge a PR from a CMake co-author / Kitware employee that sits two doors from the CMake maintainers and just add the docs about changing style wishes ourselves? ;-)

Yes, all CMAKE_... flags in CMake are intended to be set only to overwrite defaults. Typical use cases: Toolchains, super builds, or manual CLI calls that enforce a specific compiler, specific flags or a specific CXX standard. The extra block in there just extends compiler support, e.g. when pybind11 is called as subproject for projects running with more sciency/experimental/HPC compilers than the big three in our CI.

[wjakob]

Happy to merge it, but I don't have the clock cycles to look into documenting this atm. (Remote working with a two-year old who is bored out of her mind has been quite the challenge.) @ax3l -- if you want this merged, can you open a new PR based on this one?

[ax3l]

Sure thing, please see #2184.

[wjakob]

Merged via #2184

[wjakob]

Thanks @chuckatkins and @ax3l