Cabal: bindir/libdir/datadir

Simon Marlow simonmar at
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
by me.

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
back again?).


More information about the Libraries mailing list