<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Sep 30, 2016 at 6:05 PM, Tillmann Rendel <span dir="ltr"><<a href="mailto:rendel@informatik.uni-tuebingen.de" target="_blank">rendel@informatik.uni-tuebingen.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So I think my question is: Could stack be persuaded somehow to make `stack install gtk3` "just work" by doing all the necessary incantations? I'm aware why `cabal install gtk3` can neither install gtk2hs-buildtools nor install the C library, but maybe stack could make a different tradeoff there.</blockquote><div><br></div><div>I've actually put direct thought into this. I'm partially responsible for the relative ease on Windows now -- previously Stack wasn't setting up the environment correctly for MinGW -- it was providing an MSYS environment instead, which means full POSIX emulation rather than just a mostly-sufficient translation layer. This distinction is also why there are separate 'pkg-config' and '<span style="font-size:12.8px">mingw-w64-x86_64-pkg-config</span>' (and unfortunately you want the latter, here).</div><div><br></div><div>I almost added the system update and pkg-config (since .cabal files directly reference it) to the msys installation process in my PR, but I was dissuaded from it by some comments about issues they had trying to do the same with git:</div><div><br></div><div>1. it can fail due to network issues, and getting a consistent state with good user feedback out of a return code inside a sub-shell is more work than anyone's wanted to do yet.</div><div><br></div><div>2. the fact that msys includes an arbitrary set of packages, and in fact can upgrade itself without stack's permission or even knowledge, is damaging to the intended promise of reproducible builds.</div><div><br></div><div>On top of that, this is solely a Windows concern -- stack doesn't have any desire or reason to be a system package manager elsewhere. So I decided the better option is a separate windows-specific tool, which knows how to deal with stack environments (that's in public library code, so yay) and provides a convenience wrapper for pacman which, among other things, attaches the correct big ugly prefix to package names for you.</div><div><br></div><div>I got as far as deciding that it would either be named "stacman" or "Jenga" and then put it on the shelf because, with the environment stuff worked out, plain stack is no longer too much of a hassle for me personally. But, I'm certain it's a plausible and not even particularly difficult project.</div></div></div></div>