appveyor: don't rewrite the system mingw#4137
Conversation
|
ARGH, this didn't even queue an appveyor build?! 😡 |
The 'appveyor' branch is useful for testing AppVeyor builds.
|
what do the failures look like? |
fb7e4bb to
91a701c
Compare
|
@tkelman We used to download newer mingw-w64's and overwrite |
|
Sorry, I realize I didn't answer your question. The error was with moving our |
91a701c to
0431be2
Compare
|
so it does, guess that was good enough at the time and avoided needing to modify path. appveyor may have changed permissions or what's installed by default? |
| branches: | ||
| only: | ||
| - master | ||
| - appveyor |
There was a problem hiding this comment.
it should build pr's if the webhook is configured right, there may have just been a delivery failure?
I think without a regex this would need to be an exact match anyway
There was a problem hiding this comment.
Yes - that's correct; there was just a weird webhook failure here. But it encouraged me to add the appveyor branch so that we could build appveyor in isolation and not burn unnecessary travis builds.
Yes, that's right - AppVeyor updated its mingw installation, and I think changed permissions then, which is why we noticed this. |
Download mingw-w64 into our build directory and execute it there, don't try to overwrite the system's mingw.
0431be2 to
408a7b7
Compare
|
Is it even reasonable to always re-download MinGW? Shouldn't we just be using whatever AppVeyor is currently providing? |
|
AppVeyor only provides the 32 bit mingw-w64. There's an issue to provide the x86_64 version as well. Once they do, I think we should reconsider using the installed versions. |
|
the download should be cached here |
|
Ah okay, that explains it. Thanks! |
Trying to chase down the new appveyor build failures...