Support running in existing MSYS2 installation

[conklech]

The great virtue of MSYS2 on Windows is that we now have access to a real package manager for C dependencies. Binary packages are available for recent versions of GTK, webkit, and many other useful packages that have historically been difficult or impossible to install on Windows.

It would be great if building a package that uses gtk from a clean Windows system were as simple as:

1. Install stack
2. Install MSYS2; open mingw shell
3. $ pacman -S mingw-w64-x86_64-gtk3 pkg-config
4. $ stack build

Right now this doesn't work; the gtk2hs builders complain that the pkg-config packages glib, cairo, etc. aren't available. Is this because Stack redirects paths to its built-in git+MSYS2 installation?

(I'd be glad to provide logs, more information, etc.; I don't know how much of this is a known limitation and I don't want to dump details unnecessarily.)

[snoyberg]

One possible solution here is: have stack detect if something like sh is on the PATH and, if so, not include its own portable Git. What do you think?

[conklech]

Come to think of it, there could be at least three mingw installations in play: the one packaged with GHC, the one packaged with Git/Stack, and the user's version installed with MSYS2. Are they all compatible? Are they interchangeable? Which one should be in the environment?

Detecting sh would probably be too lenient: we need at least git for our own use.

[snoyberg]

MinGW and msys are two different beasts. At least in everything I've done in MinGHC and stack, we never override the MinGW provided by GHC, as wonky things can happen (AFAIU at least).

stack doesn't actually require Git, it just uses it if available, so not adding it in wouldn't break anything. Alternatively, PortableGit provides the git command in a different directory from all other executables, so we could selectively include one or the other directory.

[snoyberg]

We seem to have stalled on this. @conklech do you have any feedback on my last point?

[conklech]

@snoyberg Unfortunately I don't have much feedback on that post.

I suppose the best route for progress would be to determine where the pkg-config errors in the original post actually come from; it might be a narrower problem than we've assumed, and unrelated to having parallel MSYS installations or otherwise easily fixable.

Interestingly, the presence of the pkg-config tool itself changes the error message given. Without it, this happens:

$ stack build
cairo-0.13.1.0: configure
glib-0.13.1.0: configure

--  While building package glib-0.13.1.0 using:
      C:\\Users\\chris_000\\AppData\\Local\\Programs\\stack\\i386-windows\\ghc-7.8.4\\bin\\runhaskell.exe -package=Cabal-1.18.1.5 
        -clear-package-db -global-package-db 
        -package-db=C:\Users\chris_000\AppData\Roaming\stack\snapshots\i386-windows\lts-2.14\7.8.4\pkgdb\ 
        C:\msys64\tmp\stack9100\glib-0.13.1.0\Setup.hs --builddir=.stack-work\dist\i386-windows\Cabal-1.18.1.5\ configure --user 
        --package-db=clear --package-db=global 
        --package-db=C:\Users\chris_000\AppData\Roaming\stack\snapshots\i386-windows\lts-2.14\7.8.4\pkgdb\ --constraint=base==4.7.0.2 
        --constraint=bytestring==0.10.4.0 --constraint=containers==0.5.5.1 --constraint=text==1.2.0.6 --constraint=utf8-string==1 
        --libdir=C:\Users\chris_000\AppData\Roaming\stack\snapshots\i386-windows\lts-2.14\7.8.4\lib 
        --bindir=C:\Users\chris_000\AppData\Roaming\stack\snapshots\i386-windows\lts-2.14\7.8.4\bin 
        --datadir=C:\Users\chris_000\AppData\Roaming\stack\snapshots\i386-windows\lts-2.14\7.8.4\share 
        --docdir=C:\Users\chris_000\AppData\Roaming\stack\snapshots\i386-windows\lts-2.14\7.8.4\doc\glib-0.13.1.0 
        --htmldir=C:\Users\chris_000\AppData\Roaming\stack\snapshots\i386-windows\lts-2.14\7.8.4\doc\glib-0.13.1.0 
        --haddockdir=C:\Users\chris_000\AppData\Roaming\stack\snapshots\i386-windows\lts-2.14\7.8.4\doc\glib-0.13.1.0
    Process exited with code: ExitFailure 1
    Logs have been written to: "D:\\Tools\\gtk2hs-hello\\.stack-work\\logs\\glib-0.13.1.0.log"

    [1 of 2] Compiling Gtk2HsSetup      ( Gtk2HsSetup.hs, dist\setup-wrapper\Gtk2HsSetup.o )
    [2 of 2] Compiling Main             ( SetupMain.hs, dist\setup-wrapper\Main.o )
    Linking dist/setup-wrapper\setup.exe ...
    Configuring glib-0.13.1.0...
    setup.exe: The program pkg-config version >=0.9.0 is required but it could not
    be found.

Installing pkg-config (pacman -Su pkg-config) changes the error to setup.exe: The pkg-config package cairo version >=1.2.0 is required but it could not be found. The output of pkg-config --moduleversion cairo is 1.14.2.

So the installed pkg-config is at least on the path; I don't know how it works well enough to guess at why it (or setup.exe?) can't find the installed cairo.

[snoyberg]

What's the output for stack exec -- pkg-config --moduleversion cairo?

[conklech]

(For the record, it's --modversion; I messed that up.)

$ pkg-config --modversion cairo
1.14.2

$ stack exec -- pkg-config --modversion cairo
Package cairo was not found in the pkg-config search path.
Perhaps you should add the directory containing `cairo.pc'
to the PKG_CONFIG_PATH environment variable
No package 'cairo' found

There's some path mangling going on:

$ which pkg-config
/usr/bin/pkg-config

$ stack exec -- which pkg-config
/c/msys64/usr/bin/pkg-config

They're the same file; /c/msys64 is the root of the MSYS2 installation.

[conklech]

I should have included the contents of the environment variable:

$ echo $PKG_CONFIG_PATH
/mingw64/lib/pkgconfig:/mingw64/share/pkgconfig

$ stack exec -- echo $PKG_CONFIG_PATH
C:\msys64\mingw64\lib\pkgconfig;C:\msys64\mingw64\share\pkgconfig

[snoyberg]

OK, I do think that having an option to skip the local MSYS and use your existing one will solve the problem. I'm implementing this now. Could you test master once I push this?

[conklech]

Err, hold on a sec. Per this msys2 bug report, I should be using the package mingw-w64-x86_64-pkg-config instead of pkg-config.

With that package, things seem to work fine from stack's end; glib, cairo, etc. build and install happily. (pango fails building for an apparently-unrelated reason, so I can't test yet.)

Possibly NOTABUG.

[snoyberg]

Heh, that's interesting. Nonetheless, I see value in offering the ability to not use a custom MSYS, so I'll continue with the (almost complete) implementation.

[conklech]

Fine by me; and yes, I'll test once you push it.

[snoyberg]

Pushed, but completely untested by me. Caveat emptor (though I'll build it on Windows myself now).

[snoyberg]

(Should have mentioned: try stack --skip-msys build)

[conklech]

stack --skip-msys build seems to work fine. stack --skip-msys update also seems to work fine, even though it's using some completely different git install (msysgit, I think) that happens to be on $PATH.

Any other things to try?

[snoyberg]

I don't think so. Thanks for confirming, closing this issue.

[asampal]

Would it be possible to configure stack to default to 'skip-msys' ?

[mgsloan]

@asampal That's covered in #846 , which is indeed something that ought to be done.

[ekmett]

@conklech, the removal of pkg-config and installation of mingw-w64-x86_64-pkg-config fixed a similar issue for me. I'd earlier installed cmake to build something and it brought in pkg-config transitively, so later on stack was trying to build with it.

[neontorrent]

@conklech Spent a whole night on this and it turns out using mingw-w64-x86_64-pkg-config solves the problem. Now I am carefully examining all the packages under msys/*.