Improve pkg-config/dependencies installation story on Windows

[akhra]

Currently it's up to the Windows user (and undocumented!) to use stack exec -- pacman to set up pkg-config and any dependencies.

At worst, stack should be able to handle pacman -Sy and the pkg-config installation, and then provide a more helpful error message if a package is missing (i.e. how to search for and install it).

If a package's pkg-config name is always the suffix of its pacman package name -- I'm not sure of this, but it seems likely -- then I don't see why stack can't automate the whole process.

[borsboom]

Would you be able to provide a more concrete example/proposal? For example, demonstrate a particular problem and then propose the way Stack should handle it better?

[byorgey]

I just ran into this too. I had no idea I was supposed to do anything involving pacman until @mgsloan pointed me at this ticket. At the very least, a concrete proposal would be to have stack print a message at the end of stack setup saying something like "You should do stack exec -- pacman -Sy and then you can use stack exec -- pacman -S foobar to install any pkg-config packages needed for building".

[akhra]

@byorgey That would be helpful, yeah. But it should be automatable (near as I can tell pacman names do always match pkg-config), and very likely should be performed while building dependencies for reasons relating to #1587: pacman -S foobar is generally the wrong library. Ideally we want to run pacman -S [mingw-[w64|w32]-[x86_64|i686]-]foobar for each permutation of those found by pacman -Ss foobar or, more intelligently, for whichever matches the current build environment. Failing full automation, a stackman command that does the right thing would be good.

But none of this really helps until #1587 is solved, because right now stack is building binaries for Windows that think full POSIX support is available. Quite a few will crash if not run within the msys shell. I've been getting a hair farther with that every time I tackle it, but I've had limited opportunities to do so.

[akhra]

Well, never mind that blockade. :) While working through #1587 I've come to the conclusion that the best solution here is to provide a wrapper for pacman which is aware of stack's environment but is able to run outside of it (because installs should optimally happen in the POSIX msys shell, which is not provided by stack exec after PR #1909). Doing it any other way runs into the same issues that caused git to be dropped (#1046); not to mention that since MSYS2 is a resolver-versioned tool, it seems wrong for stack-proper to do anything that might damage build reproduciblity.

In theory we could do better, but we'd need our own controlled MSYS fork and Stackage would have to include its packages. And I'm not volunteering for that!

[varosi]

Is it possible to have "mingw" section in .yaml file to control mingw third-party libs installations similar to "nix" section?

[mpilgrem]

As a Windows user (Windows 11, PowerShell), I was having difficulties with a pkgconfig-depends field in a .cabal file. I knew that I could install the C libraries by tracking them down in MSYS2 Packages and installing the relevant mingw64 package into the stack-supplied MSYS2 with stack exec -- pacman -S <mingw-w64-x86_64-package_name>. What I did not know was that I also needed to install the pkg-config tool into the stack-supplied MSYS2:

> stack exec -- pacman -S mingw-w64-x86_64-pkg-config

and then add, to the front of the PKG_CONFIG_PATH environment variable, the path to the ming64w\lib\pkgconfig subfolder of the stack-supplied MSYS2. The path to the stack-supplied MSYS2 can be deduced by inspecting the beginning of the output of stack path --extra-library-dirs. On my machine, for example:

> stack path --extra-library-dirs
C:\Users\mikep\AppData\Local\Programs\stack\x86_64-windows\msys2-20210604\mingw64\lib, C:\Users\mikep\AppData\Local\Programs\stack\x86_64-windows\msys2-20210604\mingw64\bin

so I can see the path to the stack-supplied MSYS2 is C:\Users\mikep\AppData\Local\Programs\stack\x86_64-windows\msys2-20210604. PKG_CONFIG_DIR can be set (temporarily) with:

> $Env:PKG_CONFIG_DIR="<path_to_stack-supplied_MSYS2>\ming64w\lib\pkgconfig;"+$Env:PKG_CONFIG_DIR

It seems to me that it would help Windows users if, on Windows:

1. The stack-supplied MSYS2 came with the pkg-config tool already installed;
2. The stack environment already added the path to the relevant \ming64w\lib\pkgconfig subfolder to the start of the PKG_CONFIG_DIR environment variable;
3. The stack path command included the path the stack-supplied MSYS2 as one of its paths/options; and
4. the online guide to stack provided some help on this topic.

EDIT: I have revised my understanding above. I had more than one MSYS2 on my machine and that may have caused some odd behaviour. I now understand that pkg-config.exe already looks for .pc files in the appropriate place without the need for PKG_CONFIG_PATH. That is:

> stack exec -- pkg-config --variable=pc_path pkg-config
C:\Users\mikep\AppData\Local\Programs\stack\x86_64-windows\msys2-20210604\mingw64\lib\pkgconfig;C:\Users\mikep\AppData\Local\Programs\stack\x86_64-windows\msys2-20210604\mingw64\share\pkgconfig

So, 2. and 3. above would not be needed.

[andreasabel]

NB: As of today, the newer/better package pkgconf is recommended (rather than pkg-config).