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...?