GitLab

* Doxygen needs `RECURSIVE = YES` in order to parse the `detail` subdir.

* The `-W` warnings-as-errors option for sphinx doesn't work with the
  makefile build. Switched to calling sphinx directly.

* Fix "citation [cppimport] is not referenced" warning.

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.

buster's python3-numpy and -scipy packages now support Python 3.6.

gcc 7 is now in debian testing ("buster"), with a proper stable upstream
release; this updates the associated travis-ci to use "buster" (rather
than "sid"), and removes the build from allow_failures.

Debian stretch was just released, so `debian:testing` and
`debian:stetch` are starting to diverge; this commit keeps the travis-ci
docker image on stretch for gcc6 and clang3.9.

Debian has also moved gcc 7 from experimental to unstable, so this
switches the gcc7 build to `sid`.  Once it migrates to `testing` I'll
switch the gcc 7 build docker image to `testing` and take it out of
failure-allowed.

The clang 4.0/cpp17 build wasn't enabling -flto because the system
linker didn't like the output generated by clang for some reason.  This
switches the build to use llvm's lld instead, which lets -flto work
again (and links considerably faster, too).

numpy 1.13.0 fails with pypy 5.7.1, so this upgrades to 5.8.0.  I've
also uploaded pre-built .whl files to imaginary.ca (checked every 4
hours and rebuilt if needed), and list that as an extra pypi location
under the pypy pip install to avoid the long travis pypy build times for
a new release or branch.

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.

The job is using the released clang and stable-branch libc++, which
wasn't the case when it was added.  Leave the g++7/c++17 in
allow_failures for now as it's still a pre-release compiler (and pulled
from debian experimental).

Breathe was previously installed from the git master because of a bug
in the released version. The fix has since migrated to PyPI.

[skip appveyor]

Various bash variables that are only used in the travis-ci script and
don't need to propagate (e.g. to cmake) are being pointlessly exported;
this removes these `export`s.

This uses the trusty container rather than docker for the clang 4.0
build.  It also caches the local libc++ installation so that it doesn't
need to be compiled every time, which should speed up the job
considerably.

This applies several changes to the non-docker travis-ci builds:

- Make all builds use trusty rather than precise.  pybind can't really
  build in precise anyway (we install essentially the entire toolchain
  backported from trusty on every build), and so this saves needing to
  install all the backported packages during the build setup.
- Updated the 3.5 build to 3.6 (via deadsnakes, which didn't backport
  3.6 to ubuntu releases earlier than trusty).
- As a result of the switch to trusty, the BAREBONES build now picks up
  the (default installed) python 3.5 installation.
- Invoke pip everywhere via $PYTHON -m pip rather than the pip
  executable, which saves us having to figure out what the pip
  executable is, and ensures that we are using the correct pip.
- Install packages with `pip --user` rather than in a virtualenv.
- Add the local user python package archive to the travis-ci cache
  (rather than the pip cache).  This saves needing to install packages
  during installation (unless there are updates, in which case the
  package and the cache are updated).
- Install numpy and scipy on the pypy build.  This has to build from
  source (and so blas and fortran need to be installed on the build),
  but given the above caching, the build will only be slow for the first
  build after a new numpy/scipy release.  This testing is valuable:
  numpy has various behaviour differences under pypy.
- Added set -e/+e around the before_install/install blocks so that a
  failure here (e.g. a pip install failure or dependency download
  failure) triggers a build failure.
- Update eigen version to latest (3.3.3), mainly to be consistent with
  the appveyor build.
- The travis trusty environment has an upgraded cmake, so this
  downgrades cmake (to the stock trusty version) on the first couple
  jobs so that we're still including some cmake 2.8.12 testing.

The gcc versions in Debian stretch (gcc 6) and experimental (gcc 7)
incorporate the upstream gcc fixes.

We no longer need a nightly build now that 5.7 is released (and the
current nightly 5.8 is failing).

This adds a linux docker clang 4.0 with libc++ and c++1z build.

Nightlies for pypy no longer run on Ubuntu 12.04; change the pypy build
distribution to the travis-ci trusty (i.e. 14.04) beta container.

The pypy build was also installing numpy and scipy for the *system*
python version, which was pointless; this also adds a guard to the
eigen/numpy/scipy install code with a !PYPY check.

* Make tests buildable independently

This makes "tests" buildable as a separate project that uses
find_package(pybind11 CONFIG) when invoked independently.

This also moves the WERROR option into tests/CMakeLists.txt, as that's
the only place it is used.

* Use Eigen 3.3.1's cmake target, if available

This changes the eigen finding code to attempt to use Eigen's
system-installed Eigen3Config first.  In Eigen 3.3.1, it exports a cmake
Eigen3::Eigen target to get dependencies from (rather than setting the
include path directly).

If it fails, we fall back to the trying to load allowing modules (i.e.
allowing our tools/FindEigen3.cmake).  If we either fallback, or the
eigen version is older than 3.3.1 (or , we still set the include
directory manually; otherwise, for CONFIG + new Eigen, we get it via
the target.

This is also needed to allow 'tests' to be built independently, when
the find_package(Eigen3) is going to find via the system-installed
Eigen3Config.cmake.

* Add a install-then-build test, using clang on linux

This tests that `make install` to the actual system, followed by a build
of the tests (without the main pybind11 repository available) works as
expected.

To also expand the testing variety a bit, it also builds using
clang-3.9 instead of gcc.

* Don't try loading Eigen3Config in cmake < 3.0

It could FATAL_ERROR as the newer cmake includes a cmake 3.0 required
line.

If doing an independent, out-of-tree "tests" build, the regular
find_package(Eigen3) is likely to fail with the same error, but I think
we can just let that be: if you want a recent Eigen with proper cmake
loading support *and* want to do an independent tests build, you'll
need at least cmake 3.0.

Recent gcc snapshots (both gcc 7 snapshots and recent gcc 6 stable
branch snapshots) are triggering an upstream gcc bug when -flto is
enabled (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79296).  This has
been hitting the gcc-7 builds for a while now, but is going to start
hitting the debian testing builds in a few days as well.

The issue is triggered by using -flto in combination with structs or
classes declared in a function, as done in test_alias_initialization,
test_isses, test_methods_and_attributes (and possibly more).

I'm subscribed to the upstream bug, and will submit another PR to
reenable LTO once a fixed gcc is available.

The gcc-7 build also generates some warnings; just ignore them for now
(by turning off -Werror).

Adds a 32-bit (debian) build to travis-ci.

* Make 'any' the default markup role for Sphinx docs

* Automate generation of reference docs with doxygen and breathe

* Improve reference docs coverage

Both are no longer needed: debian testing has Python 2.7.13 final now,
and wheels of numpy and scipy are available.

* Temporarily allows osx homebrew Python 3.6 to fail.

https://github.com/pybind/pybind11/pull/570#issuecomment-269120613

"Homebrew just got Python 3.6 (brew install python3), but numpy and scipy don't have binary wheels for 3.6 yet so it's trying to compile from source and failing."

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

This commit includes modifications that are needed to get pybind11 to work with PyPy. The full test suite compiles and runs except for a last few functions that are commented out (due to problems in PyPy that were reported on the PyPy bugtracker).

Two somewhat intrusive changes were needed to make it possible: two new tags ``py::buffer_protocol()`` and ``py::metaclass()`` must now be specified to the ``class_`` constructor if the class uses the buffer protocol and/or requires a metaclass (e.g. for static properties).

Note that this is only for the PyPy version based on Python 2.7 for now. When the PyPy 3.x has caught up in terms of cpyext compliance, a PyPy 3.x patch will follow.

Current debian testing has Python 2.7.13-RC1, which has a serious
regression (upstream https://bugs.python.org/issue5322) which should be
reverted for RC2 (or the final 2.7.13).  Ignore build failures for this
build test temporarily (with the intention of reverting this commit in a
couple of weeks once it stops failing, i.e. when debian testing picks up
an updated python 2.7 release).

Add a build using g++-7 snapshot from debian experimental.  This build
is set to allow failures without triggering an overall build failure
(since this is an experimental compiler with experimental support for a
future C++ standard).

https://github.com/sphinx-doc/sphinx/issues/3212

A flake8 configuration is included in setup.cfg and the checks are
executed automatically on Travis:

* Ensures a consistent PEP8 code style
* Does basic linting to prevent possible bugs

- Try to update and upgrade twice (with a brief pause between attempts)
  to deal with occassional spurious server failures or repository race
  conditions.  Do the same for the main package install.
- Use dist-upgrade instead of upgrade for updating the image
- Add -q to the upgrade and install commands to make apt less verbose.

This adds a tool that checks style (currently just for tabs instead of
spaces in files under include/tests/docs) and produces a travis-ci build
failure if any problems are found.

Installing something outside the project directory from a cmake
invocation is overly intrusive; this changes tests/CMakeLists.txt to
just fail with an informative message instead, and changes the
travis-ci builds to install pytest via pip or apt-get.

ccache on Travis was never configured properly so the setting never
actually did anything. Enabling ccache for real brings other issues:
due to the way the preprocessor is handled, some of the Python header
macros produce bogus compiler warnings (which in turn produce errors
with -Werror). ccache also requires additional configuration on OS X
and docker. It would reduce compile time by ~30 seconds at best, so
it's not worth the trouble.

[skip appveyor]

This build makes sure everything still works without optional
dependencies (numpy/scipy/eigen) and also tests the automatic
discovery functions in CMake (Python version, C++ standard).

[skip appveyor]

Pytest is a development dependency but we can make it painless by
automating the install using CMake.