Relocable packages with library
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. This usually makes sense but sometimes it is also useful to have library with relocable data directory. 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". 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 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? Regards, Krasimir
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 please.
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.
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. Duncan
On Fri, Jun 20, 2008 at 11:37 AM, Duncan Coutts
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
participants (2)
-
Duncan Coutts -
Krasimir Angelov