* Add debugging info about so size to build output
This adds a small python script to tools that captures before-and-after
.so sizes between builds and outputs this in the build output via a
string such as:
------ pybind11_tests.cpython-35m-x86_64-linux-gnu.so file size: 924696 (decrease of 73680 bytes = 7.38%)
------ pybind11_tests.cpython-35m-x86_64-linux-gnu.so file size: 998376 (increase of 73680 bytes = 7.97%)
------ pybind11_tests.cpython-35m-x86_64-linux-gnu.so file size: 998376 (no change)
Or, if there was no .so during the build, just the .so size by itself:
------ pybind11_tests.cpython-35m-x86_64-linux-gnu.so file size: 998376
This allows you to, for example, build, checkout a different branch,
rebuild, and easily see exactly the change in the pybind11_tests.so
size.
It also allows looking at the travis and appveyor build logs to get an
idea of .so/.dll sizes across different build systems.
* Minor libsize.py script changes
- Use RAII open
- Remove unused libsize=-1
- Report change as [+-]xyz bytes = [+-]a.bc%
This makes the output considerably easier to use: it now highlights (in
red) matched tabs (instead of just listing the filenames), and adds
line numbers to both the tabs check and the space-less if check outputs.
The check-style exit status wasn't being propagated properly because
the loops were running in a subshell (and so the change the the
`errors` variable wasn't in the active command shell). This fixes it
by running the greps in subshells and the loops in the main shell.
This also avoids the if(/for(/while( style check on
tests/CMakeLists.txt, since it *does* have if() statements with no space
that are producing error messages, but that is (acceptable) CMake style.
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.
Fixes#365. `sysconfig.get_config_var('SO')` already returns the correct
PYTHON_MODULE_EXTENSION, even for debug builds, so there is no need to
add anything else manually.
When run on windows in a venv, PYTHON_LIBRARY pointet to a non-existant
location in the virtual environment directory.
This has been fixed by testing if the path exists and, if not, trying
an alternative path, relative to the PYTHON_INCLUDE_DIR.
If the alternative path doesn't exit as well, an error will be raised.
