summaryrefslogtreecommitdiff
path: root/appveyor.yml
AgeCommit message (Collapse)AuthorFilesLines
2019-11-14Appveyor: Quickly fix meson build.Prodea Alexandru-Liviu1-1/+1
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>
2019-10-18appveyor: Move appveyor script into .appveyor directoryDylan Baker1-3/+3
This clears out the scripts directory completely Reviewed-by: Adam Jackson <ajax@redhat.com>
2019-10-16appveyor: Cache meson's wrap downloadsDylan Baker1-0/+1
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>
2019-10-10appveyor: Add support for meson as well as scons on windowsDylan Baker1-30/+10
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>
2019-01-25appveyor: Revert commits adding Cygwin support.Jose Fonseca1-13/+30
This reverts commits 00ad77b9f683e561b1ac45fbb89eb2bafe45c8c6 and 5334dafee265d78abdfcf30e2c693e0791bfecf5. 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.
2019-01-07appveyor: Add a Cygwin build scriptJon Turney1-5/+14
2019-01-07appveyor: put build steps in a script, rather than inline in appveyor.ymlJon Turney1-29/+3
2018-10-16appveyor: Cache pip's cache files.Jose Fonseca1-0/+2
It should speed up the Python packages installation. Reviewed-by: Roland Scheidegger <sroland@vmware.com>
2018-10-16appveyor: Update to newer Mako/winflexbison versions.Jose Fonseca1-4/+5
As that's what most people are bound to use. Reviewed-by: Roland Scheidegger <sroland@vmware.com>
2018-10-16appveyor: Update to MSVC 2017.Jose Fonseca1-6/+6
That's what we (and I suppose most people out there) are using now. Reviewed-by: Roland Scheidegger <sroland@vmware.com>
2018-08-21appveyor: Set git core.autocrlf setting to true.Jose Fonseca1-0/+7
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>
2018-06-16appveyor: Consume LLVM 5.0.1.Jose Fonseca1-2/+2
https://ci.appveyor.com/project/jrfonseca/mesa/build/47 Reviewed-by: Roland Scheidegger <sroland@vmware.com>
2018-02-22appveyor: Build with MSVC 2015.Jose Fonseca1-5/+5
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>
2017-03-29appveyor: Update dependencies.Jose Fonseca1-4/+6
- Use explicit versions everywhere. - Avoid deprecate `--egg` pip option. Reviewed-by: Roland Scheidegger <sroland@vmware.com>
2016-09-13appveyor: Update winflexbison download URL.Jose Fonseca1-1/+1
This particular version got moved into a `old_versions` subdirectory.
2016-08-11appveyor: Force Visual Studio 2013 image.Jose Fonseca1-0/+2
It seems the default build image is now Visual Studio 2015, and Visual Studio 2013 is not installed.
2016-08-11appveyor: Install pywin32 extensions.Jose Fonseca1-0/+2
AppVeyor build images seem to have been upgraded to Python 2.7.12, but no longer have pywin32 pre-installed.
2016-04-14appveyor: Run unit tests.Jose Fonseca1-0/+3
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
2016-02-03appveyor: Bump shallow clone depth.Jose Fonseca1-2/+9
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 dac2964f3ebd96d5ac227984ab0cd79c2c3b2a1a and 6f428328d34bed16edb8709e4a117eb710d7893d 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>
2015-12-08appveyor: Cache winflexbison archive.Jose Fonseca1-3/+7
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.
2015-12-02appveyor: Initial integration.Jose Fonseca1-0/+62
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>
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-26 19:42:57 +0000