On 8/10/07, ross@soi.city.ac.uk wrote:

I also think an option to move dist would introduce too many complications.

Lack of such option, in my opinion, shows how immature Cabal is as a build tool. I'd use the option if it existed, even with the drawbacks. However, I agree this might be too much for now - there's more important things broken in Cabal, and there's not enough developers. Too bad adding the option is likely to only get harder as Cabal expands and gets more users who rely on current behavior. Best regards, Esa

On Fri, 2007-08-10 at 17:49 +0100, ross@soi.city.ac.uk wrote:

Quoting Duncan Coutts :

...

It's not clear to me what the configure --scratchdir= option is for. It seems to be only used by hugs for building and installing and it defaults to dist/scratch.

Yes, --scratchdir is a hack for the Hugs build that allows it to build libraries that can be run inplace prior to installation. An option to move the whole of dist wouldn't be a replacement.

Do you think we can do this in a more similar way to how we do it for ghc? We need to do inplace running/linking/registration for most compilers it seems.

I also think an option to move dist would introduce too many complications.

I've been looking at cleaning up the install dirs and build dirs code and I don't think it'd be that bad. If people wanted it however, it would require passing the same flag to each stage, since that directory is essential to find the saved configuration. Another alternative is to do what autoconf does which is to allow running setup from another directory, so it always puts it's config relative to the current directory, but the .cabal file could be specified and not necessarily live in the current directory. That'd allow the whole source tree to be read-only. eg: cabal configure --package=../../foo/foo.cabal cabal build cabal install Duncan