Relocable packages with library

Duncan Coutts duncan.coutts at
Fri Jun 20 05:37:35 EDT 2008

On Thu, 2008-06-19 at 19:56 +0200, Krasimir Angelov wrote:
> Hi,
> I have a package that contains one library, one executable and a
> number of data files. If the package contains only executables then
> the generated Paths_<pkgid>.hs on Windows uses the executable location
> in order to calculate the datadir, libdir, etc directories. This is
> useful feature if someone wants relocable binary distributions. If the
> package has library then these directories are fixed. The initial
> reason was that many executables might be linked to this library and
> they should share the same data files.

Or if the library itself needs to use the data files.

> This usually makes sense but sometimes it is also useful to have
> library with relocable data directory.

Note that once we have shared libs we should be able to have relocatable
libs because on windows we can find the location of the dll.

> In this case it will be relative to the location where the executable
> linked with it is installed. If several executables are linked with
> the same library then they can be installed in one directory and they
> still will be able to share the common data directory. This is
> currently the common situation, since all executables are installed in
> "c:\Program Files\Haskell\bin".

True, though nothing stops people from installing things anywhere they

> I already experienced the problem with haddock-2.0 where the
> precompiled binary expects that some files are installed in
> "C:\builds\haddock-2\install\haddock-\html" which is wrong of
> course. Now I strike the same problem with another package.

I'm not sure I understand. The haddock package is a program so it should
already be relocatable.

Oh, wait, I see, haddock is actually a library and a program.

> I propose to either add flag to configure saying that directories in
> Paths_<pkgid>.hs should be relative or to make them relative in all
> cases.
> What do you think?

The problem as I see it is that it is the author who wants to have
relative paths but the user can put things wherever they like and
there's nothing we can do to stop them.

How about this alternative that should solve the haddock example. We
make the data files per-lib or per-exe. So data files for an exe can be
relocatable even if the ones for the lib are not.

Of course that means the exe would have to be the one to find the data
files and pass them to functions in the library.


More information about the cabal-devel mailing list