GitLab

pybind11_add_module fails because FindPythonLibsNew.cmake try to link PythonXX.lib, but the first letter "p" should be lowercase.

This variable is a CMake community standard to set the C++
standard of a build. Document it in favor of the previous variable,
which stays as a legacy flag for existing projects.

https://cmake.org/cmake/help/v3.17/variable/CMAKE_CXX_STANDARD.html

Add Python 3.8 to considered versions in CMake for additional
hints.
https://cmake.org/cmake/help/v3.2/module/FindPythonLibs.html

On some linuxes, /usr/include belongs to GCC and the standard
libraries that work with clang are in /usr/lib/clang/8.0.0 or
some variation thereof.

This results in errors such as:

```
/../lib64/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../include/c++/8.3.0/bits/cxxabi_init_exception.h:38:10: fatal error: 'stddef.h' file not found

```

during extraction.

Recent versions of clang.cindex include [code][1] that converts
the internal byte strings to python str for you.

  [1]: https://github.com/llvm-mirror/clang/blob/master/bindings/python/clang/cindex.py#L72

Since the module is named FindPythonLibsNew, PythonLibsNew_FOUND should be set appropriately.

* Issue #1532: Incompatible config options, /MP vs /Gm for MSVC in DEBUG

pybind11 headers passed via the `pybind11_add_module` CMake
function can now be included as `SYSTEM` includes (`-isystem`).

This allows to set stricter (or experimental) warnings in
calling projects that might throw otherwise in headers
a user of pybind11 can not influence.

builds against a python debug library were unreliable and
could lead to symbol errors during linking.

Setting the `Py_DEBUG` define is necessary when linking
against a debug build:

https://stackoverflow.com/questions/39161202/how-to-work-around-missing-pymodule-create2-in-amd64-win-python35-d-lib

https://docs.python.org/2/c-api/intro.html#debugging-builds

https://docs.python.org/3.6/c-api/intro.html#debugging-builds

Found via `codespell`

Non-user facing. 
Found using `codespell -q 3`

[skip appveyor]

CMAKE_CXX_STANDARD is only available on CMake >= 3.1. If the flag is
set, we avoid initializing PYBIND11_CPP_STANDARD.

This updates the compilation to always apply hidden visibility to
resolve the issues with default visibility causing problems under debug
compilations.  Moreover using the cmake property makes it easier for a
caller to override if absolutely needed for some reason.

For `pybind11_add_module` we use cmake to set the property; for the
targets, we append to compilation option to non-MSVC compilers.

Make sure `LibsNew` runs correctly if called after the old `Libs`.

Currently select_cxx_standard(), which sets PYBIND11_CPP_STANDARD when
not externally set, is only called from pybind11_add_module(), but the
embed target setup (which runs unconditionally) makes use of
${PYBIND11_CPP_STANDARD}, which isn't set yet.  This commit removes the
`select_cxx_standard` function completely and just always runs the
standard detection code.

This also tweaks the detection code to not bothering checking for the
`-std=c++11` flag when the `-std=c++14` detection succeeded.

./tools/check-style.sh fails on stock OS X currently; this fixes it:

- use pipes directly rather than exec redirection (macOS's ancient
  version of bash fails with the latter)
- macOS's ancient bash doesn't support '\e' escapes in `echo -e`;
  replace with \033 instead
- BSD grep doesn't support GREP_COLORS, but does allow GREP_COLOR.
  Adding both doesn't hurt GNU grep: GREP_COLOR is deprecated, and won't
  be used when GREP_COLORS is set.
- BSD grep doesn't collapse multiple /'s in the listed filename, so
  failures under `include/` would should up as
  `include//pybind11/whatever.h`.  This removes the / from the include
  directory argument.

Minor other changes:
- The CRLF detection runs with -l, so GREP_COLORS wasn't doing
  anything; removed it.
- The trailing whitespace test would trigger on CRLFs, but the CR would
  result in messed up output.  Changed the test to just match trailing
  spaces and tabs, rather than all whitespace.

At this point, there is only a single test for interpreter basics.

Apart from embedding itself, having a C++ test framework will also
benefit the C++-side features by allowing them to be tested directly.

All targets provided by pybind11:

* pybind11::module - the existing target for creating extension modules
* pybind11::embed - new target for embedding the interpreter
* pybind11::pybind11 - common "base" target (headers only)