GitLab

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.

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.

Rather than adding an `if [ -n "$DOCS" ]` as a separate install
instruction, this simplifies the travis-ci logic to do the pip/venv
setup in the `before_install` hook, leaving the install hook to just
install the needed packages.

This makes the default install script simpler: it doesn't need to check
NATIVE_DEPS or DOCS because both of those now override `install`
anyway, so the top-level `install` is really just the install for the
gcc-4.8 and osx builds; the docker builds and docs build override
install completely.

This switches the travis-ci build to build the docs in a dedicated
build rather than as part of the regular linux/osx builds.

The current linux/g++ testing (using a backported g++-4.8 on a
4-year-old Ubuntu) is quite ancient.  It's good as a baseline level of
support, but it means we aren't testing g++'s C++14 support at all
(which is why #334 happened).

This commit adds a docker-based travis-ci build using the debian
"testing" distribution, which will give us both another test system
(with different versions of build tools), while, more importantly, also
adding a build and test run using g++ in C++14 mode.