Add msys2 support

Environments Windows
1

It would be nice to have MSYS2 environment like the one present in AppVeyor


Raw MSYS2 is enough because MinGW already present in the environment can work with tools from MSYS2.

Right now I get by by installing it at the beginning through chocolatey but it takes almost 10 minutes from valuable build time and doesn’t provide the latest version.

1 Like
2

I concur with this request.

Another approach is to provide an updated Git for Windows.
Currently it is 2.19.1
https://chocolatey.org/packages/git.install is at 2.22.0

Git for Windows now supports updating using the msys pacman.

I get an error when I try to upgrade git.install

$ choco update git.install

Chocolatey v0.10.11

DEPRECATION NOTICE - choco update is deprecated and will be removed or

replaced in version 1.0.0 with something that performs the functions

of updating package indexes. Please use `choco upgrade` instead.

Upgrading the following packages:

git.install

By upgrading you accept licenses for the packages.

You have git.install v2.19.1 installed. Version 2.22.0 is available based on your source(s).

Progress: Downloading git.install 2.22.0... 100%

git.install v2.22.0 [Approved]

git.install package files upgrade completed. Performing other installation steps.

Using Git LFS

Installing 64-bit git.install...

ERROR: Running ["C:\ProgramData\chocolatey\lib\git.install\tools\Git-2.22.0-64-bit.exe" /VERYSILENT /SUPPRESSMSGBOXES /NORESTART /NOCANCEL /SP- /LOG /COMPONENTS="icons,assoc,assoc_sh,ext,ext\shellhere,ext\guihere,gitlfs,icons\quicklaunch" ] was not successful. Exit code was '1'. See log for possible error messages.

The upgrade of git.install was NOT successful.

Error while running 'C:\ProgramData\chocolatey\lib\git.install\tools\chocolateyInstall.ps1'.

See log for details.

Chocolatey upgraded 0/1 packages. 1 packages failed.

See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).

Failures

- git.install (exited 1) - Error while running 'C:\ProgramData\chocolatey\lib\git.install\tools\chocolateyInstall.ps1'.

See log for details.
3

See also How do I use mingw and msys2 shells? ; adding a separate msys introduces its own problems as it conflicts with the different cygwin dll’s already loaded by Git Bash.

4

Joining the request.
Would be more useful to use Msys2 in the first place instead of Git Bash.

Despite all the possible problems, appveyor.com managed to have msys2 in their images so Travis now has to catch up.

1 Like
5

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.

1 Like
6

To me, the right solution for that looks like there whould be a separate image for each of those environments.