I’d highly recommend against mixing the “MinGW” Chocolatey package with an MSYS2 environment. In my case, Bazel failed to build Google Test from source until I added a choco uninstall -y mingw
command before my choco upgrade -y msys2 bazel
command. Effectively I’m installing and using the mingw-w64-x86_64-toolchain
package inside MSYS2 instead of using the mingw
Chocolatey package.
As my reply shows, you need to go via RefreshEnv.cmd
(to reload PATH
from the Registry) and msys2_shell.cmd
(to set up several other environment variables required by the MSYS2 environment, e.g. MSYSTEM
and MSYSCON
).
It’s easy to do so in Travis (including caching to reduce setup time) using a few lines:
before_install:
- |-
case $TRAVIS_OS_NAME in
windows)
[[ ! -f C:/tools/msys64/msys2_shell.cmd ]] && rm -rf C:/tools/msys64
choco upgrade --no-progress -y msys2
taskkill //IM gpg-agent.exe //F
;;
esac
before_cache:
- |-
case $TRAVIS_OS_NAME in
windows)
$msys2 pacman --sync --clean --noconfirm
;;
esac
cache:
directories:
- $HOME/AppData/Local/Temp/chocolatey
- /C/tools/msys64
I agree it would be convenient to have it preinstalled in the image, given its popularity. The real issue, though, is how is the user supposed to enter that environment (e.g. the $msys2
specifier in before_cache
above)? Note that even AppVeyor has this problem – your appveyor.yml
can contain code for Bash (on Linux) / cmd.exe
(on Windows) or PowerShell but it’s still up to you to enter the MSYS2/MinGW64 environment to run your commands.
While I’ve solved it for MSYS2 / MinGW-64, it isn’t the only special environment that the user may need to enter. Cygwin, Visual Studio, Embarcadero C++Builder, and many other development tools have their own “build environments” that need to be similarly entered.
I’d say what Travis needs is more documentation regarding these use cases. Trying to automate everyone’s use case may not be possible in general. (There’s also this other problem with disk space.)
UPDATE: Entered this PR, comments welcome.