Zengtudor
/
pybind11
mirror of https://github.com/pybind/pybind11.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
pybind11/.appveyor.yml

68 lines
2.3 KiB
YAML
Raw Permalink Normal View History

appveyor CI script
2015-10-18 15:04:24 +00:00
version: 1.0.{build}
Add VS 2017 build, and bump conda to 3.6 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).
2017-03-12 03:03:23 +00:00
image:
- Visual Studio 2017
- Visual Studio 2015
appveyor: legacy build on win32
2015-10-23 08:21:09 +00:00
test: off
AppVeyor: use parallel builds My group now has a subscription to AppVeyor pro, which also permits running parallel builds on the open source projects.
2017-04-05 15:02:34 +00:00
build:
parallel: true
Improve CI test coverage: eigen, numpy and C++14
2016-07-29 22:15:01 +00:00
platform:
- x64
Add VS 2017 build, and bump conda to 3.6 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).
2017-03-12 03:03:23 +00:00
- x86
appveyor: legacy build on win32
2015-10-23 08:21:09 +00:00
environment:
matrix:
Speed up AppVeyor build (#1021) 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.
2017-08-23 15:18:57 +00:00
- PYTHON: 36
Make PYBIND11_CPP_STANDARD work under MSVC 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.
2017-05-09 18:37:48 +00:00
CPP: 14
Speed up AppVeyor build (#1021) 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.
2017-08-23 15:18:57 +00:00
CONFIG: Debug
- PYTHON: 27
Make PYBIND11_CPP_STANDARD work under MSVC 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.
2017-05-09 18:37:48 +00:00
CPP: 14
Speed up AppVeyor build (#1021) 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.
2017-08-23 15:18:57 +00:00
CONFIG: Debug
Make PYBIND11_CPP_STANDARD work under MSVC 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.
2017-05-09 18:37:48 +00:00
- CONDA: 36
CPP: latest
Speed up AppVeyor build (#1021) 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.
2017-08-23 15:18:57 +00:00
CONFIG: Release
Add VS 2017 build, and bump conda to 3.6 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).
2017-03-12 03:03:23 +00:00
matrix:
Skip VS2015/x86 builds 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.
2017-04-05 22:09:02 +00:00
exclude:
- image: Visual Studio 2015
platform: x86
Make PYBIND11_CPP_STANDARD work under MSVC 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.
2017-05-09 18:37:48 +00:00
- image: Visual Studio 2015
CPP: latest
- image: Visual Studio 2017
CPP: latest
platform: x86
appveyor CI script
2015-10-18 15:04:24 +00:00
install:
Improve CI test coverage: eigen, numpy and C++14
2016-07-29 22:15:01 +00:00
- ps: |
if ($env:PLATFORM -eq "x64") { $env:CMAKE_ARCH = "x64" }
Add support for boost::variant in C++11 mode 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.
2017-08-08 14:02:31 +00:00
if ($env:APPVEYOR_JOB_NAME -like "*Visual Studio 2017*") {
$env:CMAKE_GENERATOR = "Visual Studio 15 2017"
$env:CMAKE_INCLUDE_PATH = "C:\Libraries\boost_1_64_0"
Build /permissive- under VS2017 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.
2017-10-22 15:06:52 +00:00
$env:CXXFLAGS = "-permissive-"
Add support for boost::variant in C++11 mode 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.
2017-08-08 14:02:31 +00:00
} else {
$env:CMAKE_GENERATOR = "Visual Studio 14 2015"
}
Improve CI test coverage: eigen, numpy and C++14
2016-07-29 22:15:01 +00:00
if ($env:PYTHON) {
if ($env:PLATFORM -eq "x64") { $env:PYTHON = "$env:PYTHON-x64" }
$env:PATH = "C:\Python$env:PYTHON\;C:\Python$env:PYTHON\Scripts\;$env:PATH"
Fix pip issues on AppVeyor CI (#1369)
2018-04-22 12:04:12 +00:00
python -m pip install --upgrade pip wheel
python -m pip install pytest numpy --no-warn-script-location
Improve CI test coverage: eigen, numpy and C++14
2016-07-29 22:15:01 +00:00
} elseif ($env:CONDA) {
if ($env:CONDA -eq "27") { $env:CONDA = "" }
if ($env:PLATFORM -eq "x64") { $env:CONDA = "$env:CONDA-x64" }
$env:PATH = "C:\Miniconda$env:CONDA\;C:\Miniconda$env:CONDA\Scripts\;$env:PATH"
Add Catch framework for testing embedding support and C++-side features 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.
2017-03-23 16:27:32 +00:00
$env:PYTHONHOME = "C:\Miniconda$env:CONDA"
Port tests to pytest 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.
2016-08-12 11:50:00 +00:00
conda install -y -q pytest numpy scipy
Improve CI test coverage: eigen, numpy and C++14
2016-07-29 22:15:01 +00:00
}
- ps: |
AppVeyor: Update eigen to 3.3.3 The 3.3.2 changelog indicates it has some VS 2017 fixes. Updating to see if that avoids the random build failures.
2017-04-10 18:48:24 +00:00
Start-FileDownload 'http://bitbucket.org/eigen/eigen/get/3.3.3.zip'
7z x 3.3.3.zip -y > $null
Add support for boost::variant in C++11 mode 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.
2017-08-08 14:02:31 +00:00
$env:CMAKE_INCLUDE_PATH = "eigen-eigen-67e894c6cd8f;$env:CMAKE_INCLUDE_PATH"
appveyor CI script
2015-10-18 15:04:24 +00:00
build_script:
Add Catch framework for testing embedding support and C++-side features 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.
2017-03-23 16:27:32 +00:00
- cmake -G "%CMAKE_GENERATOR%" -A "%CMAKE_ARCH%"
-DPYBIND11_CPP_STANDARD=/std:c++%CPP%
-DPYBIND11_WERROR=ON
-DDOWNLOAD_CATCH=ON
-DCMAKE_SUPPRESS_REGENERATION=1
Improve CI test coverage: eigen, numpy and C++14
2016-07-29 22:15:01 +00:00
- set MSBuildLogger="C:\Program Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll"
Speed up AppVeyor build (#1021) 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.
2017-08-23 15:18:57 +00:00
- cmake --build . --config %CONFIG% --target pytest -- /m /v:m /logger:%MSBuildLogger%
- cmake --build . --config %CONFIG% --target cpptest -- /m /v:m /logger:%MSBuildLogger%
- if "%CPP%"=="latest" (cmake --build . --config %CONFIG% --target test_cmake_build -- /m /v:m /logger:%MSBuildLogger%)
Add Catch framework for testing embedding support and C++-side features 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.
2017-03-23 16:27:32 +00:00
on_failure: if exist "tests\test_cmake_build" type tests\test_cmake_build\*.log*