Relocable packages with library

[Krasimir Angelov]

On Fri, Jun 20, 2008 at 11:37 AM, Duncan Coutts
<duncan.coutts at worc.ox.ac.uk> wrote:
>
> 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.

Yes, it will be nice to have.

>> 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
> please.

Of course. This is only the default situation.

>> 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-2.0.0.0\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.

Exactly.

>> 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.

In this case we should have one Paths_lib and one Paths_exe module.

Krasimir