GitLab

Building with the (VS2017) /permissive- flag puts the compiler into
stricter standards-compliant mode.  It shouldn't cause the compiler to
work differently--it just disallows some non-conforming code--so should
be perfectly fine for the test suite under all VS2017 builds.

This commit also fixes one failure under non-permissive mode.

The `latest` build remains as is, but all others are modified to:

* Use regular Python instead of conda. `pip install` is much faster
  than conda, but scipy isn't available. Numpy is still tested.

* Compile in debug mode instead of release.

* Skip CMake build tests. For some reason, CMake configuration is very
  slow on AppVeyor and these tests are almost entirely CMake.

The changes reduce build time to about 1/3 of the original. The `latest` 
config still covers scipy, release mode and the CMake build tests, so 
the others don't need to.

In C++11 mode, `boost::apply_visitor` requires an explicit `result_type`.
This also adds optional tests for `boost::variant` in C++11/14, if boost
is available. In C++17 mode, `std::variant` is tested instead.

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.

Under MSVC we were ignoring PYBIND11_CPP_STANDARD and simply not
passing any standard (which makes MSVC default to its C++14 mode).

MSVC 2015u3 added the `/std:c++14` and `/std:c++latest` flags; the
latter, under MSVC 2017, enables some C++17 features (such as
`std::optional` and `std::variant`), so it is something we need to
start supporting under MSVC.

This makes the PYBIND11_CPP_STANDARD cmake variable work under MSVC,
defaulting it to /std:c++14 (matching the default -std=c++14 for
non-MSVC).

It also adds a new appveyor test running under MSVC 2017 with
/std:c++latest, which runs (and passes) the
`std::optional`/`std::variant` tests.

Also updated the documentation to clarify the c++ flags and add show
MSVC flag examples.

While builds are randomly failing, fast_finish is counterproductive.

Will reenable this once appveyor stabilizes.

(https://gitlab.kitware.com/cmake/cmake/issues/16783)

The 3.3.2 changelog indicates it has some VS 2017 fixes.  Updating to
see if that avoids the random build failures.

/m also doesn't seem to have made the builds any faster.

AppVeyor just added support for excluding specific jobs; thhis commit
cuts the number of builds down to 6 from 8 by eliminating the VS2015 x86
builds.

My group now has a subscription to AppVeyor pro, which also permits
running parallel builds on the open source projects.

This adds VS 2017 to the build matrix, plus various other small
appveyor build changes:

- conda version bumped from 3.5 to 3.6
- build newer versions/architectures/python first (i.e. VS2017/x64/3.6
  is the first build, VS2015/x86/2.7 is the last)
- stop building after a job failure: often a build failure in one
  occurs everywhere; this just stops processing jobs (freeing them up
  for other PRs) if an error is hit.

Annoyingly, appveyor doesn't allow excluding tests: i.e. the test matrix
is always dense (appveyor issue 386), so for now we'll just run
everything.  (Once appveyor issue 386 is resolved, we can come back and
cut this down to 4-5 builds).

Add a BUILD_INTERFACE and a pybind11::pybind11 alias for the interface
library to match the installed target.

Add new cmake tests for add_subdirectory and consolidates the
.cpp and .py files needed for the cmake build tests:

Before:
tests
|-- test_installed_module
|   |-- CMakeLists.txt
|   |-- main.cpp
|   \-- test.py
\-- test_installed_target
    |-- CMakeLists.txt
    |-- main.cpp
    \-- test.py

After:
tests
\-- test_cmake_build
    |-- installed_module/CMakeLists.txt
    |-- installed_target/CMakeLists.txt
    |-- subdirectory_module/CMakeLists.txt
    |-- subdirectory_target/CMakeLists.txt
    |-- main.cpp
    \-- test.py

With this change both C++ and Python write to sys.stdout which resolves
the capture issues noted in #351. Therefore, the related workarounds are
removed.

pytest can capture test output both globally (controlled by the cmd line
flag --capture) or locally (`capsys` and `capfd` fixtures). Enabling both
methods at the same time causes problems on Windows: test output is not
captured sometimes, resulting in test failure. This happens seemingly at
random.

This workaround disables global output capture ("-s", i.e. "--capture=no")
leaving only the local capture fixtures. As a side-effect test output on
AppVeyor CI is a little messy, but this will have to do until a better
solution is found.

Use simple asserts and pytest's powerful introspection to make testing
simpler. This merges the old .py/.ref file pairs into simple .py files
where the expected values are right next to the code being tested.

This commit does not touch the C++ part of the code and replicates the
Python tests exactly like the old .ref-file-based approach.