The kludgy method we use to get env vars from vcvarsall.bat into our
environment doesn't correctly handle env var values which contain
newlines.
The BUILD_SOURCEVERSIONMESSAGE environment variable contains the
entirety of the commit message. If a line containing an equals sign
appears in the commit message, we could have problems.
Unset that environment variable to workaround this problem.
Now we have some information in CI logs about what compiler is actually
being used, fix some places where an unexpected compiler is being picked
up.
Avoid picking up gcc-objc and gfortran from PATH in vs2017 image for VS
test runs.
Use clang for objc/objc++ in MSYS2 clang test runs, rather than picking
up gcc from path.
Also install gfortran for fortran tests on Cygwin.
It looks like BOOST_ROOT is now set in the azure v2017 image (relevant
change seems to be [1], pre-installing boost)
Remove BOOST_ROOT from the environment to prevent attempting to use a
boost which is incompatible with the compiler.
(an MSVC boost should be compatible with clang-cl, but has problems, see
c7a3e810)
[1] https://github.com/Microsoft/azure-pipelines-image-generation/pull/732
This installs a Boost distribution with built binaries for Windows, so
we can have test coverage of both (i) boost components which are
header-only libraries, and (ii) boost components which have
separately-compiled libraries.
(This duplicates the behaviour from appveyor of using Boost 1.64 with
VS1027 (the first version which provides pre-built binaries for that),
and Boost 1.60 for VS2015 (the oldest Boost provided by appveyor))
Don't install Boost when using clang-cl, as there appear to be issues in
either Boost or clang-cl which prevent that from working well.
Be more prescriptive about the static linker to use in test case
common/143. This avoids using DMD's 'lib' in preference to clang-cl's
'llvm-lib' when both of them are in PATH
Add a JDK installed in vs2015 image to PATH, so java tests can be run
JDK appear to be installed in several places, so we can always pick a
different one:
C:\java\jdk\jdk1.8.0_102\bin\
C:\Program Files\Java\jdk1.8.0_102\bin
C:\Program Files (x86)\Java\jdk1.8.0_102\bin
Add Windows SDK tools to PATH (for rc). This requires INCLUDE to be set.
lld-link doesn't seem to default to searching the correct directories, so
LIB needs to be set.
The easiest way to get the correct setting of INLCUDE and LIB env vars seems
to be to import the VS env vars, then revert the PATH.
Import MS-MPI env vars set by installer in registry to environment
Skip testing we can apply a version constraint to MPI when version isn't
known (as is the case for MS-MPI)
(These tests have never worked in appveyor)
v1:
Add an azure-pipelines.yml
Don't check source line endings if autocrlf is on
Handle origin-only refs in skip_ci
Add .py to PATHEXT for the benefit of test_find_program()
Publish logs as build artifacts and publish test results
v2:
Use .gitattributes to override autocrlf
Move tmpdir, so it's not a subdir of source directory, otherwise it gets
included in line-ending checks.
Use serial build numbers, rather than date.dailybuildnumber
Workaround for #3239 is no longer needed now a fix has been commited
Tweak test results and artefact naming
Wait for MS-MPI installers to complete
Publish test results even if tests had an error
Also, use '^' to escape newlines in appveyor-install.bat to avoid an
absurdly long line, remove some unnecessary quotation, and alphabetically
sort packages
Also, define the _XOPEN_SOURCE feature test macro in the boost test to avoid
'not declared in this scope' warnings for pthread_rwlock_init(), etc.
This reverts commit 92c2bb7519.
This is no longer needed, as a patched ninja is now available from the
standard Cygwin package repository, and prevents me from accidentally
breaking CI when changing things in my personal package repository.
* 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.