Windows installer should add MSYS to extra-prog-path/extra-lib-dirs/...

[23Skidoo]

The problem: build-type: Configure packages like old-time and network don't build out of the box on Windows, unless you perform the following steps:

Add to the cabal config file the following lines:

extra-prog-path: C:\Program Files\Haskell Platform\7.10.3\msys\usr\bin
extra-lib-dirs: C:\Program Files\Haskell Platform\7.10.3\mingw\lib
extra-include-dirs: C:\Program Files\Haskell Platform\7.10.3\mingw\include

In the program-location subsection of the cabal config file add

gcc-location: C:\PROGRA1\HASKEL1\7.10.3\mingw\bin\gcc.exe

(gcc-location is probably not needed nowadays)

IMO, the HP installer should do this automatically. I can't think of any objections, and #207 doesn't mention any either.

/cc @randen @ndmitchell

[gbaz]

There were some concerns about messing with people's cabal config files automatically, so as I recall there was some discussion around this. and additionally if there is no cabal config file, it wouldn't have been created until cabal is first run anyway. But herbert suggests a few nice approaches: a) basically, test if a user-config file exists, and if not run user-config in it and then alter the file. And whether or not the cabal file is initialized by the installer can be a user-configurable option. b) at a minimum if the instructions on what to add to the file aren't displayed when the installer is run, we can add them. (he also notes that a) could be easier at some point if we add a `cabal user-config init --with-msys-location=...` flag (which can even be snuck into cabal 2.0?)

[hvr]

I think it's generally a good idea to run cabal user-config init always after the HP installer runs.

Because an old config file may be lurking around, and that's generally a source of confusion (i.e. when your config file was created by some ancient cabal 1.18, and you use it with cabal 2.0, I wouldn't be surprised there to be undesired effects). It may even point to some old msys install location from a previous HP installation... (in this context cabal user-config diff --with-msys-locatio=... may be interesting as well)

So by running cabal user-config init (with --with-msys-location=... for windows) always by the installer, you could make the user aware about a pre-existing config file (as the command would fail w/o --force flag given), and ask the user to inspect & resolve the situation manually. Also this provides a simple test whether cabal is able to write a file to the installing user's ~/.cabal/config location, which may catch setup/configuration problems early on.

---

Here's the --help output just for reference:

$ cabal user-config init --help
Display and update the user's global cabal configuration.

Usage: cabal user-config init
   or: cabal user-config diff
   or: cabal user-config update

When upgrading cabal, the set of configuration keys and their default values
may change. This command provides means to merge the existing config in
~/.cabal/config (i.e. all bindings that are actually defined and not commented
out) and the default config of the new version.

init: Creates a new config file at either ~/.cabal/config or as specified by
--config-file, if given. An existing file won't be overwritten unless -f or
--force is given.
diff: Shows a pseudo-diff of the user's ~/.cabal/config file and the default
configuration that would be created by cabal if the config file did not exist.
update: Applies the pseudo-diff to the configuration that would be created by
default, and write the result back to ~/.cabal/config.

Flags for user-config:
 -h --help        Show this help text
 -v --verbose[=n] Control verbosity (n is 0--3, default verbosity level is 1)
 -f --force       Overwrite the config file if it already exists.

[Mistuke]

Hmmm I may have an alternate solution.

What if we change the way HP is packaged. So HP can use the GHC provided by MSYS2 or build a GHC packaged using this patch https://phabricator.haskell.org/D3637 which I'll land for 8.4.

The idea of it is to allow GHC to use the CC on the path. So the idea is HP would package the same GCC and utils that we do (you can just use pacman to install the tarballs) and then GHC would pick those up.

Configure would then find the libraries in their standard locations, no extra configuration needed. But as a bonus as well, user libraries installed with pacman will also automatically be picked up, without the need for any path munging.

This also means that users have a standard place aside from System32 to drop libraries in that we'll automatically pick up. and Includes etc.

I've been looking for alternative ways to package Windows binaries and this is one of the solutions I'm considering.

[gbaz]

I'm not sure I follow. HP already packages the same GCC and utils. Its just we have to add the paths to the cabal file so the options get passed. Additionally, this allows us to ensure that we use the correct gcc for ghc rather than e.g. the one installed with an existing cygwin installation (which may in general want to take precedence on the path?). Could you expand on concretely what changes to the hp installer would take place, and how cabal etc would interact differently?

…

On Sun, Jun 11, 2017 at 12:58 PM, Tamar Christina ***@***.***> wrote: Hmmm I may have an alternate solution. What if we change the way HP is packaged. So HP can use the GHC provided by MSYS2 or build a GHC packaged using this patch https://phabricator.haskell.org/D3637 which I'll land for 8.4. The idea of it is to allow GHC to use the CC on the path. So the idea is HP would package the same GCC and utils that we do (you can just use pacman to install the tarballs) and then GHC would pick those up. Configure would then find the libraries in their standard locations, no extra configuration needed. But as a bonus as well, user libraries installed with pacman will also automatically be picked up, without the need for any path munging. This also means that users have a standard place aside from System32 to drop libraries in that we'll automatically pick up. and Includes etc. I've been looking for alternative ways to package Windows binaries and this is one of the solutions I'm considering. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#279 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABEt2Ta0gdD8J3b0SUfw2ZMy70MXiNWuks5sDByfgaJpZM4N2YZr> .

[Mistuke]

So at the moment, from your post above I think the current situation with HP is:

1. you provide a stock GHC with the bundled bindist
2. you provide the GCC shipped In the bindists
3. You don't change the settings file to point to the outside GCC.

This is why the paths need fudging at the moment. Concretely this proposal is to

1. provide a GHC which uses the system compiler
2. provide the GCC and tools installed MSYS2 wide as you do now

GHC uses GCC to determine locations of libraries. As far as I am aware cabal does not detect any paths.
configure currently fails because it gets the path to the GCC provided with GHC, which does not know about /usr/lib etc. By changing to using the system compiler GHC will be able to see any package it can see, and so configure would work out of the box without any other paths required.

The GCC driver (which will be removed soon in https://phabricator.haskell.org/D3592) pointed all base directories inward.

as would any package installed with pacman without any other change, I think more packages would work out of the box this way.

[gbaz]

I don't think this is enough for us to change our behavior. Its not just finding libraries thats affected. its finding other build tools, and even sh, etc. themselves which depends on having the extra-bin-dirs in path. Its typically the configure step of build-type-configure scripts that fails.

[Mistuke]

Sure it won't work if we expect the user to be able to use any term to build stuff. Then you would need this.
But how do most users use platform, from a mintty shell for instance it should all work, since that starts a bash session.

Afterall I can install network without needing any extra options in my msys2 install. The proposal is to make the Windows install virtually identical to the unix ones. We don't specify all these paths on Linux either.

Given the fact that you'll need a unix like shell to execute configure anyway, this isn't an issue is it?

[gbaz]

the unix like shell comes with the msys we distribute. so on a raw system with no dev packages installed, a fresh hp install (plus cabal config files) lets you install build-type configure packages out of the box.

[23Skidoo]

@Mistuke

Sure it won't work if we expect the user to be able to use any term to build stuff.

I should point out that this ticket is specifically about making it possible to build stuff with cabal from powershell/cmd.exe/whatever out of the box. The HP MSYS terminal case works already.

[Mistuke]

I should point out that this ticket is specifically about making it possible to build stuff with cabal from powershell/cmd.exe/whatever out of the box. The HP MSYS terminal case works already.

Right, so this ticket is about getting cabal to find libraries installed in the environment? e.g. using pacman?

As I don't think getting Configure based packages to work in any shell would work with this approach since powershell/cmd etc won't be able to understand configure anyway and cabal doesn't know how to start a shell to run the configure script in. (this would also be a nice addition btw).

But yeah this would be a useful addition as a lot of people don't read the step 2 on the install page.
I think something more general would be more helpful though:

cabal user-config add {key} {value}
cabal user-config remove {key} {value}
cabal user-config list {list}

so HP installer would just issue a series of

cabal user-config add extra-prog-path {path}

It can then use list to figure out if an existing HP installation is there and then properly ask the user what to do.

This would also be useful to everyone on all platforms I think, and to people like me who automate GHC/cabal setups or just simply scripting tests.

If we want to get something like this in the next Cabal release we have to move quick, I believe the deadline is fairly close? What do you think @hvr , @gbaz and @23Skidoo ?

[Mistuke]

If it's too much for the next release, I think an undocumented --with-msys-location= would also be fine.

[23Skidoo]

cabal doesn't know how to start a shell to run the configure script in. (this would also be a nice addition btw).

Actually no, it looks for sh in the environment. See https://github.com/haskell/cabal/blob/master/Cabal/Distribution/Simple.hs#L707

So if it can find an appropriate sh, it can build e.g. network when run from cmd.exe.

[23Skidoo]

cabal user-config add/... would be nice to have, but implementing it can get a bit involved. Patches welcome ofc!

[hvr]

@23Skidoo @Mistuke

Do I sense correctly we're heading towards an agreement on having as a temporary solution an undocumented/hidden handshake as suggested in #279 (comment), i.e.

cabal user-config init --with-msys-location=...

?

[23Skidoo]

I'm fine with adding a temporary undocumented thingie for this.

[Mistuke]

Yup so am I. And good to know about sh, I wasn't aware of that!

…

On Wed, Dec 13, 2017, 13:41 Mikhail Glushenkov ***@***.***> wrote: I'm fine with adding a temporary undocumented thingie for this. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#279 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABH3KcZF5_MdAhOsylIZMxV0RRYWIpvmks5s_9QggaJpZM4N2YZr> .

[randen]

HP will need to sync with cabal pull request: haskell/cabal#5008

[gbaz]

This is in the new cabal 2.2 branch. It would be really nice to implement this with the new platform release.

[gbaz]

fixed!