ericbav...@openmailbox.org writes: > From: Eric Bavier <bav...@member.fsf.org> > > The first of these patches lets search-path-as-list function correctly when a > pattern is given and the 'directory file type is specified. > > The second adds a native-search-paths field to our ghc package. It modifies > our haskell-build-system to install a package-specific package database with > each haskell library. GHC insists on a binary package cache file called > 'package.cache' to be in each directory listed in GHC_PACKAGE PATH, so we > uniquely name the package database directories, and use a file-pattern to add > those to GHC_PACKAGE_PATH. > > The benefit of this over the current situation is that one gets the benefit of > `guix package --search-paths`. Currently, after installing ghc packages, the > user needs to know to manually add > ~/.guix-profile/lib/ghc-7.8.4/package.conf.d to their GHC_PACKAGE_PATH. GHC > package recipes would no longer need to propagate runtime dependencies, and > 'guix environment' also works nicely out-of-the-box:: > > $ guix environment --ad-hoc ghc ghc-attoparsec > $ ghc-pkg list > /gnu/store/...-ghc-mtl-2.1.3.1/lib/ghc-7.8.4/ghc-mtl-2.1.3.1.conf.d > base-4.7.0.2 > ghc-prim-0.3.1.0 > integer-gmp-0.5.1.0 > mtl-2.1.3.1 > rts-1.0 > transformers-0.3.0.0 > /gnu/store/...-ghc-regex-base-0.93.2/lib/ghc-7.8.4/ghc-regex-base-0.93.2.conf.d > array-0.5.0.0 > base-4.7.0.2 > bytestring-0.10.4.0 > ... > /gnu/store/4vvmngz1w8ccm7v7mk4f4dxk45834464-ghc-attoparsec-0.13.0.0/lib/ghc-7.8.4/ghc-attoparsec-0.13.0.0.conf.d > array-0.5.0.0 > attoparsec-0.13.0.0 > ... > > Though, as you can see in this example, libraries may be listed more than > once. As far as I can tell at this point, that is just an aesthetic detail. > > Future work might involve filtering build-only library dependencies from the > generated package database. We could probably also remove the ghc package > database creation during profile generation. > > I'd be insterested in hearing others' thoughts on this approach.
Hi Eric, sounds like a good approach to work around the "package.cache" clash. I have a couple of questions: * If I understand correctly, the configuration files of dependencies are copied in a unique directory for each package. Instead of copying would a symlink work? (There are literally thousands of packages on Hackage and hopefully Guix will get more of them.) * Some Haskell libraries have a rather large list of dependencies. For this reason I can imagine that in some situations GHC_PACKAGE_PATH could grow rather long. This thought made me wonder if there is a maximum length to the value of environment variables that we could possibly hit. Regards, Fede
