simonmar at microsoft.com
Fri Oct 7 07:35:21 EDT 2005
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
So, here's the plan. options to ./setup configure:
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 &
Additionally, we add --copy-root=<dir> with the old meaning of
--copy-prefix, and deprecate --copy-prefix (or just change --copy-prefix
More information about the Libraries