The new implementation will correctly pick boost from 3 possible
locations on windows and two locations on posix compatible OSs.
The new search algorithm also differentiates between debug and
release builds of Boost and multi or single threading builds.
It was also decided to map "Meson modules" to Boost software libraries
and not Boost modules since it there are a lot of options regarding
linking. Some modules can even be used either as headers-only or with
dynamic linking.
This commit also fixes a bug that prevented header-only use on Windows.
Fixes: #2274#2239#1803#669
This was a good idea in theory, but in practice it has made Codecov
completely useless because doc-only commits would reduce the coverage
calculated by Codecov and PRs would randomly have messages saying that
the coverage has gone up or down by a random percentage simply because
the windows builds weren't run in the last commit.
Till Codecov also has an option to skip doc-only commits, we cannot
make this change. To skip all CI, you can put "[skip ci]" or
"[ci skip]" in the commit message. This will also work with Codecov.
This way we get some testing for the patches, and speed up our builds.
My server is hosted on a UK Linode, so it should have good uptimes.
However, we should likely move this into the Docker image at least
for Linux, and perhaps put it in a CI cache for the rest.
Boost tests are disabled on Windows for now because the detection
is actually completely broken. Once that's fixed (after the release)
we can enable it again.
* Install pip on msys (which doesn't have it)
* Install codecov/coverage everywhere.
* Generate coverage XML file manually because codecov tries to call the
coverage script itself and it's in a weird place on the path.
Appveyor takes a *long* time to run (~45 minutes per commit currently),
and it does no parallelism. It is possible to skip merge requests that
only touch documentation, this commit adds that support.
Because Appveyor (and Travis) test a merge of the pull request into
master and not the branch itself this will only skip builds that only
touch docs, and not pull requests that do both doc and non-doc changes.
They are the 'weird' platforms, so we want them to be run first.
That way we don't have to wait for all the other tests before finding
out that something broke.
This reduces our CI running time by roughly half without compromising
much test coverage by much. We can mostly safely assume that very few
Meson bugs will be arch-specific with Visual Studio.
The 'Visual Studio 2017' image does not include VS2010, so we have to use
the 'Visual Studio 2015' image by default and only use the 2017 image for
msvc2017 compiler tests.
It causes the cpython tests to fail when using the x86_64 toolchain.
tachyon_module.c.obj : error LNK2019: unresolved external symbol __imp_PyLong_FromLong referenced in function phaserize
tachyon_module.c.obj : error LNK2019: unresolved external symbol __imp_PyArg_ParseTuple referenced in function phaserize
tachyon_module.c.obj : error LNK2019: unresolved external symbol __imp_PyModule_Create2 referenced in function PyInit_tachyon
c:\\python34/libs\python34.lib : warning LNK4272: library machine type 'X86' conflicts with target machine type 'x64'
ext/tachyon.pyd : fatal error LNK1120: 3 unresolved externals
This is useful to know what MSBuild.exe and Ninja we are using and
whether the correct one has been set via PATH by vcvarsall.bat and
hasn't been overwritten by appveyor.
Now we test:
MSVC 2010 + Ninja (x86)
MSVC 2015 + Ninja (x86)
MSVC 2015 + Ninja (x86_64)
MSVC 2010 + MSBuild (x86)
MSVC 2015 + MSBuild (x86)
MSVC 2015 + MSBuild (x86_64)
MSVC 2010 Express only shipped with an x86 toolchain, so we can only
test x86 for that.
Aleksey Filippov
Jussi Pakkanen
Nirbheek Chauhan
Joergen Ibsen
Niklas Claesson
Elliott Sales de Andrade
Dylan Baker
Jon Turney
Mike Sinkovsky
Nicolas Schneider