On Fri, Jun 20, 2008 at 11:37 AM, Duncan Coutts <[EMAIL PROTECTED]> 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 _______________________________________________ cabal-devel mailing list [email protected] http://www.haskell.org/mailman/listinfo/cabal-devel
