Graham Klyne
I've downloaded the latest, but I'm having a hard time getting my head around the overall structure. It feels to me a bit like a tangled ball of string, whose free end I cannot find. (This a comment on my understanding, not your code/design!)
:)
(1) Library files are copied to some place on the target filesystem. Is it intended that they can be installed anywhere, or does the LIP software choose a location? How is that location determined?
For now, this isn't addressed. This is going to be in the middle layer, the installation (Distribution.Install) layer, which is not yet implemented or specified. The only thing implemented right now is the packaging component, which is an API for helping the Implementations to locate and use packages, as well as a command-line tool for registering packages, Distribution.Package.
(2) It may be necessary that the library files need to be compiled on the target system. I think LIP must know about the compilation and related tools available for this purposes. How does LIP learn about these, and where is the information kept?
This information must be made available to the Distribution.Build package. I had originally intended it to be made available through the Distribution.Package interface, where the compilers, etc are just more packages. I'm not so convinced anymore that this is the way to go, but the idea is similar. The compilers and preprocessors, etc, might register themselves in a central location. I hope that Distribution.Build (which I'm sorta working on now, and which may end up being based on hmake) will provide an API which glosses over some of the differences between the compilers, at least for simple tools. Right now, what hmake does is close to what we need. Each installed compiler is registered with hmake somehow, and it keeps track of what features they have.
(3) When a package is installed, its presence must be made known in some way, so that other programs that use the facility can find the appropriate files. Where is such information kept, and how is it used when building a program that uses a library installed using LIP?
This is the part that is solved by Distribution.Package. The information is made available through that API.
Generally, then, LIP must know things about the installed Haskell compilers, libraries, host system type, other tools, etc. Where is this information kept, or how does LIP decide where it is kept?
It should all be available, I hope, through Haskell APIs like Distribution.Package. How will LIP _decide_ where to keep it should be answered below.
Maybe a clue I'm looking for is this: [[ systemPkgConfigLocation :: FilePath systemPkgConfigLocation = "/etc/haskell/packages.conf" ]]
But I don't see how the base config location can be hardwired into the code and be portable across systems.
It is not intended to be. Right above that you should have seen this comment: -- |Hopefully this can be grabbed from a more intelligent Directory -- module. This refers to a discussion on this list some months back: http://haskell.org/pipermail/libraries/2003-October/001462.html Well, lots of things are talked about in that thread, but the basic idea is that I think we'd win a lot by coming up with some way to populate something like those configuration file locations, but that this is a specific case of a more general problem of getting system configuration information like path separators, os versions, etc. Several solutions were discussed, but no one has raised their hand to implement one of them :) I'm hoping that this will magically happen while I'm working on the other stuff.
Also, looking at: [[ userPkgConfigLocation :: String -> FilePath userPkgConfigLocation home = home ++ "/.haskell/packages.conf" ]] I note that the Unix convention of using a name starting with '.' for "hidden" config files doesn't really work for Windows.
Yeah. With a better system, I would expect to build that path like this: userPkgConfigLocation = Directory.userConfigDirectory ++ Platform.pathSeparator ++ packages.conf Well, that's not perfect, but you get the idea. The over-arching point is that if the standard APIs provided more _infrastructure_ type stuff, like Distribution.Package and Platform.pathSeparator, then most libraries could be taken out of the ghc/nhc/hugs distributions and be more effectively distributed on their own, or in nice collections.
Looking at the API outline, and all those functions that operate on a PackageDB value, a question that occurs to me is: where does the packageDB come from? My best guess is that it's all bound up with: [[ withPackageDB :: FilePath -> (PackageDB -> IO (PackageDB, a)) -> IO a ]] which creates a PackageDB value, threads it through the I/O monad created by the second argument, puts the updated DB back to bed and returns some value derived from the process. Am I close here?
Yep. withPackageDB is the only way to get to the database contents. Look at haskell-config/Main.hs for how it's used.
I just spotted this as a possible way that LIP locates its config file ...
In the file Main.hs, I see: [[ home <- getEnv "HOME" let getPathH = getPath home ]] which value is used later in contexts that seem to name the config file.
This does seem to be rather Unix-centric (isn't HOME a Unix/Linux environment variable for the user's login directory?). And in any case, is this really something that ought to be configured on a per-user basis?
Yep. It's unixy. See above. If you have any #defines I can add to the code for windows, please pass them along. The somewhat good news is that the config file locations are only used for the --user and --system flags in haskell-config. You can also use the --config flag to pass the location of the package configuration. (snip some good ideas)
I hope my fiddling with this is more help than hindrance ... I think the project is an important undertaking for the Haskell world.
Always, and thanks :) Let me know if I answered your questions well enough. They are all on-point and relevant. peace, isaac