On 07 October 2005 12:08, Ross Paterson wrote:

...

So we could actually make $libextradir visible and explicit, i.e. change the scheme to this:

libdirrel = lib (by default) libextradir = $package/$compiler libInstDir = $prefix/$libdirrel/$libextradir

Is that what you want?

Yes, setting libdirrel independently from libextradir gives interoperability with autoconf, and also means installers don't have to mess with Cabal's placement policy unless they really want to. One could specify libdirrel with a new option or with --libdir (possibly extended with substitutions).

Ok, so I take it you'd prefer --libdir instead of --libdirrel. We can do that, but (a) we have to change --copy-prefix and (b) we have to give an error on Windows if you use --libdir to specify a path that doesn't begin with $prefix, at least for an executable. Both of these are fine by me. So, here's the plan. options to ./setup configure: --prefix=<dir> --libdir=<dir> --libsubdir=<dir> --datadir=<dir> --datasubdir=<dir> --bindir=<dir> --libexecdir=<dir> where <dir> can include $(prefix), $(package), $(compiler). libs are installed in $libdir/$libsubdir. Paths.hs-inc is auto-generated, and contains getBinDir :: IO FilePath getLibDir :: IO FilePath getDataDir :: IO FilePath getLibexecDir :: IO FilePath Executables on Windows are prefix-independent, the above functions assume they are being called by a binary in $bindir. On Unix, and for libraries on Windows, the above functions all return fixed values. On Windows, specifying any --*dir value which does not begin with $(prefix) for an executable elicits an error. I'm still not quite sure how to implement this, because the Windows version of the code is non-trival and requires a bunch of imports & flags. Additionally, we add --copy-root=<dir> with the old meaning of --copy-prefix, and deprecate --copy-prefix (or just change --copy-prefix back again?). Cheers, Simon