Cabal feedback notes

[Simon Marlow]

On 23 October 2004 10:01, Krasimir Angelov wrote:

> One way to make Cabal really portable is to move the
> entire platform specific code out of it. One example
> is
> Distribution.Simple.GHCPackageConfig.localPackageConfig
> function, which uses HOME environment variable to
> determine the user's home directory, but this doesn't
> work under Windows. The CVS System.Directory module
> already provides the getAppUserDataDirectory function
> which is more suitable (and portable) in this case.

localPackageConfig is only for GHC 6.2: in 6.4, GHC and ghc-pkg will
know where the local package conf lives, so Cabal won't need this
knowledge built-in.

> Another example is
> Distribution.Simple.Utils.findBinary. Recently I had
> updated it and now it is portable but now I see that a
> similar function is used in runghc tool but in its non
> portable version. If we move this to the standard
> libraries then we will be able to use it in both
> cases. Most of the other #ifdef-s are related to the
> filepath handling. It will be great benefit if we
> isolate it in a separate library. I already use the
> filepath routines in VSHaskell. You can see that a
> similar functions are used in haddock, happy and alex
> tools. Maybe if we agree on this it is not too late to
> add it before the next GHC release.

Last time this came up I asked for a concrete proposal, but no-one came
forward with one.  I'd do it myself, but I'm kind of busy right now.
Would someone care to whip up a list of functions & signatures?   

I'm inclined to just stick something into the libraries even if it's not
perfect.  The filename handling issue is one of those things where
trying to define a perfectly portable library is hard if not impossible,
but having *something* is going to be useful to a lot of people, and as
Krasimir says it'll have a lot of duplicated code.

Data.FilePath or System.Directory?  I'm inclined towards the latter,
since we clearly want functions that actually inspect the filesystem
(findBinary, getExecutableFilePath) along with functions that just
manipulate filenames, and it seems strange to split them up.

Cheers,
	Simon