As this required use of Python 3.8, mako module also had to be updated.
v2 - Unbind mako module version when using Meson.
Signed-off-by: Prodea Alexandru-Liviu <liviuprodea@yahoo.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
This makes us less reliant on wrap-db (and reduces the amount of
downloading that goes on during the build).
Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/1936
Acked-by: Eric Engestrom <eric.engestrom@intel.com>
This job uses the vs2017 backend of meson (msbuild) as opposed to the
ninja backend used on MacOS and Linux.
v7: - rebase on master
- remove llvm (we'll add that back later)
- remove cygwin (we'll add that back later too)
v6: - rebase on master, including the addition of cygwin
- consolidate 3 appveyor patches into this one patch
v5 - use the new b_vscrt option instead of manually specifying the crt
v4: - rebase on python3 generators
- cache meson wraps
- Build x86 instead of x86_64, since that's what the pre-built LLVM
is
- update to vs2017 from vs2015
- set the default-library to static
- use the new vscrt override
- add the /m switch to msbuild to make the build somewhat faster
Acked-by: Kristian H. Kristensen <hoegsberg@google.com>
This reverts commits 00ad77b9f6 and
5334dafee2.
This avoids Appveyor build breakage due to Cygwin, but more importantly,
there are several problems with these patches, as highlighted to my
recent mesa-dev mail. So better to revert for now, and pursue Cygwin
support after these have been address.
The git core.autocrlf setting defaults to true (ie, all text files get
checked out as CRLF on Windows), except on Appveyor where's set to
"input" (ie, all text files get checked out with the upstream
repository's line endings, which for us typically means LF.)
And this was masking on Appveyor a regression in gen_xmlpool.py
processing t_options.h with CRLF line endings.
This change makes core.autocrlf to be true, which would have enabled to
immediately catch the issue, as seen in
https://ci.appveyor.com/project/jrfonseca/mesa/build/51
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
The MSVC version we (at VMware) primarily care about from now on is
2015.
See https://ci.appveyor.com/project/jrfonseca/mesa/build/46
We can drop support for building with 2013 in a future commit. I'm not
aware of significant changes in C99/C11 support from MSVC 2013 to 2015,
but there's no point in continuing supporting old MSVC versions when
nobody cares.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
To prevent build failures when a large patch series is committed, like
happened in https://ci.appveyor.com/project/jrfonseca-fdo/mesa/build/322
due to 10 commits between dac2964f3e and
6f428328d3 where submitted before the
build slave started the git clone.
100 commits should be bigger than any patch series seen in practice, and
it takes practically the same time to download as 5 commits.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Unforunately the Appveyor -> SourceForge connection seems a bit
unreliable, causing frequent build failures while downloading
winflexbison (approx once every 2 days).
Fetching winflexbison archive into Appveyor's cache should eliminate
these.
Fetching Python modules from PyPI doesn't seem to be a problem, so they
are left alone for now, though they could eventually get the same
treatment.
AppVeyor doesn't require an appveyor.yml in the repos (in fact it has
some limitations as noted in comments below), but doing so has two great
advantages over the web UI:
- appveyor.yml can be revisioned together with the code, so instructions
should always be in synch with the code
- appveyor.yml can be reused for people's private repositories (be on
fdo or GitHub, etc.)
Acked-by: Roland Scheidegger <sroland@vmware.com>
Jose Fonseca
Prodea Alexandru-Liviu
Dylan Baker
Jon Turney