On September 24, 2015 at 11:01:53 AM, Bardur Arantsson (spam@scientician.net) wrote:

On 09/22/2015 12:11 AM, Gershom B wrote: [--snip--]

...

The proposal there would be to add an env variable (perhaps CABAL_PATH_PREFIX) which, if it existed, would be added to the path before running child processes (such as those kicked off by build-type:configure). That way windows environments could provide the Msys2 bin directory and those tools would then be made available to the configure scripts, etc.

I'm not sure I understand... what does CABAL_PATH_PREFIX add over just adding whatever is needed to the $PATH before executing cabal?

(Without having looked at the issue thread.)

I'm mainly worried about option-itis... which cabal-install is already suffering a lot from.

This is a fine question. By the way, I realized this might better be served as a cabal-path-prefix option (in cabal config) rather than an env variable, since that is more uniform. In any case, the issue is this. Suppose I want to work with MSys2, as MinGHC does. This is what lets me build against various c libraries, even in a windows environment. To do so, I need all the MSys2 tools in my path. So far, so good. But… those tools overlap in name with other tools in my path. For example, with my existing cygwin installation. And also with other tools of the same names at times that are the _windows_ versions of those common utilities. So, I want MSys2 tools in my path but _only_ when I am building cabal packages, and not otherwise. Either I manually modify my env each time I want to build a cabal package, _or_ we teach cabal to be clever and handle it for us, which is the motivation for this. Certainly, if we want a good “out of the box” experience for windows users, asking them to modify their path before they run cabal, every time they do so, is not a very great experience. —gershom

On September 24, 2015 at 11:52:51 AM, Mikhail Glushenkov (the.dead.shall.rise@gmail.com) wrote:

On 24 September 2015 at 17:06, Gershom B wrote:

...

So, I want MSys2 tools in my path but _only_ when I am building cabal packages, and not otherwise.

IIUC, 'extra-prog-path' in '~/.cabal/config' already does what you want. It looks like it also supports multiple directories, using comma as separator.

Hmm… we should investigate if that is sufficient, or if it can be changed to do so. Consider for example if we have a configure build-type, that runs an autoconf script. It is not enough that the executable we run be in the path, but also that the “path” available to the autoconf script be amended as well. So if this only changes where _cabal_ searches for executables, but does not affect the path made available to them, I think this will be insufficient? The potential overlap is certainly worth investigating, though. -g

On September 24, 2015 at 12:16:29 PM, Mikhail Glushenkov (the.dead.shall.rise@gmail.com) wrote:

On 24 September 2015 at 17:56, Gershom B wrote:

...

Consider for example if we have a configure build-type, that runs an autoconf script. It is not enough that the executable we run be in the path, but also that the “path” available to the autoconf script be amended as well.

Yes, 'extra-prog-path' also affects the PATH environment variable of the programs invoked by cabal-install:

https://github.com/haskell/cabal/blob/master/Cabal/Distribution/Simple/Progr... https://github.com/haskell/cabal/blob/master/Cabal/Distribution/Simple/Progr... https://github.com/haskell/cabal/blob/master/Cabal/Distribution/Simple/Confi...

Ah this looks like it only takes hold for the simple build-type and not “build-type: configure” for use with autoconf. (i.e. the “building network” case). I don’t quite see what’s going on in terms of how anything is implemented yet, but I would take it there would be no objections to extending this to handle the “build-type: configure” case? And of course I’d welcome any pointers as to what needs to be changed to make that work.. -gershom

On 09/24/2015 05:06 PM, Gershom B wrote:

On September 24, 2015 at 11:01:53 AM, Bardur Arantsson (spam@scientician.net) wrote:

...

On 09/22/2015 12:11 AM, Gershom B wrote: [--snip--]

...

The proposal there would be to add an env variable (perhaps CABAL_PATH_PREFIX) which, if it existed, would be added to the path before running child processes (such as those kicked off by build-type:configure). That way windows environments could provide the Msys2 bin directory and those tools would then be made available to the configure scripts, etc.

I'm not sure I understand... what does CABAL_PATH_PREFIX add over just adding whatever is needed to the $PATH before executing cabal?

(Without having looked at the issue thread.)

I'm mainly worried about option-itis... which cabal-install is already suffering a lot from.

This is a fine question. By the way, I realized this might better be served as a cabal-path-prefix option (in cabal config) rather than an env variable, since that is more uniform.

In any case, the issue is this. Suppose I want to work with MSys2, as MinGHC does. This is what lets me build against various c libraries, even in a windows environment. To do so, I need all the MSys2 tools in my path. So far, so good.

But… those tools overlap in name with other tools in my path. For example, with my existing cygwin installation. And also with other tools of the same names at times that are the _windows_ versions of those common utilities.

So, I want MSys2 tools in my path but _only_ when I am building cabal packages, and not otherwise.

Either I manually modify my env each time I want to build a cabal package, _or_ we teach cabal to be clever and handle it for us, which is the motivation for this.

Just write a little wrapper for cabal which sets the path and calls the "real" cabal...?