RE: Library Infrastructure code & help wanted
2) I also would like someone to help out with the package configuration file IO. Right now, it uses HaXmL, with no generated code. Someone who has seen HaXmL before could give me advice about how my code could be better, submit patches, or rewrite it. As discussed on libraries@haskell.org, I'm open to not using XML if someone wants to redo what I've got there (not a huge task). This parsing code is in Distribution.Package. I do want something more flexible than straight-up read/show.
I rather think that this should be considered a "sample implementation" of the Distribution.Package API. A consumer of the API should neither know nor care about the on-disk representation of the package database. I think we should specify the form of the library meta-data, at least for the default build system (by meta-data I mean the form of toolInfo in the example in sec. 3.4 of the doc). We can take the approach that we specify a very simple form, which works for most straightforward Haskell-only libraries, or we could define a rich form which will provide enough for all but the most complex library packages. I think we should start with the simple form - complex libraries will probably continue to use their own build systems for a while yet. The idea, as I understand it, is that we're going to provide two main APIs: (b) The high-level API (Distribution.Core in the example). Used by simple Setup.lhs scripts to provide generic build, install, and package registration services. Consumes Distribution.Package internally. (a) The low-level API (Distribution.Package). This is for custom build-systems which provide their own build & install, so that they can register a package. Also used by the command-line tool (haskell-config?). There may also be a mid-level API (Distribution.Build, Distribution.Install), but I'm not sure I can see a clear use for that at the moment. If not, then we don't need to specify these APIs, and they can be internal to the default build system. Also, I really think we should clarify the situation as regards multiple Haskell implementations, which seems to be glossed over at the moment. Having a single package database for all Haskell implementations seems a hard thing to implement: when GHC is installed, it will have to check whether the database and haskell-config already exist, and similarly for the other Haskell implementations. When a Haskell system is deinstalled, it has to decide whether to de-isntall haskell-config and the package database. I'd rather just admit that the Haskell systems are separate, and each provides its own implementation of Distribution.Package. Yes, this means that if you run Setup.lhs with Hugs it is different than running it with GHCi: if I want to install a package for GHC I have to run the Setup.lhs script using GHC. I believe that's the right way to go, and it's much easier from our point of view: all we have to do is agree on the Distribution.* APIs, we don't have to have any clever install/deinstall magic to deal with shared components. Cheers, Simon
"Simon Marlow"
The idea, as I understand it, is that we're going to provide two main APIs:
(b) The high-level API (Distribution.Core in the example). Used by simple Setup.lhs scripts to provide generic build, install, and package registration services. Consumes Distribution.Package internally.
Yep.
(a) The low-level API (Distribution.Package). This is for custom build-systems which provide their own build & install, so that they can register a package. Also used by the command-line tool (haskell-config?).
Yep.
There may also be a mid-level API (Distribution.Build, Distribution.Install), but I'm not sure I can see a clear use for that at the moment. If not, then we don't need to specify these APIs, and they can be internal to the default build system.
One use I thought of for the mid-level API is something to buid the module dependencies from the source code. This could definitely be reused by a wide variety of tools, including an hmake-type tool, a ctags-type tool, etc. That may be the only thing I've come up with, though.
Also, I really think we should clarify the situation as regards multiple Haskell implementations, which seems to be glossed over at the moment.
Yes, you've given me a lot to think about there...
Having a single package database for all Haskell implementations seems a hard thing to implement: when GHC is installed, it will have to check whether the database and haskell-config already exist, and similarly for the other Haskell implementations. When a Haskell system is deinstalled, it has to decide whether to de-isntall haskell-config and the package database.
I don't think that's so bad. Figuring out if a package database already exists should be a matter of having an agreed upon System.Directory.systemConfigDir. Then maybe the package database itself can tell you where to find haskell-config. I think that the compilers / interpreters installed on the system will also be stored in the "package config" database. If you're deinstalling yourself, the package database can tell you whether you're the only compiler left and thus whether to get rid of haskell-config. That said, I think there are still issues with having a single package database, for instance, what if a package configuration for one Haskell Implementation has a field that conflicts with the package configuration for another implementation. Yuck! But maybe that won't come up. For instance, right now there are separate flags for ghc, nhc, and hugs opts, and probably there should be flags for shared opts.
I'd rather just admit that the Haskell systems are separate, and each provides its own implementation of Distribution.Package. Yes, this means that if you run Setup.lhs with Hugs it is different than running it with GHCi: if I want to install a package for GHC I have to run the Setup.lhs script using GHC.
I think this would dash my hopes of being able to install a package with a single command. The idea so far has been to have some kind of haskell-interactive / runhugs-type executable /usr/bin/haskell which will execute the setup script to install and configure the package based on the already-installed compilers. Likewise, when you install a new compiler, it knows about what packages are there already for the other ones and might take a crack at building them for itself. This isn't so far fetched: elisp for emacs and xemacs already do something similar on Debian at least. peace, Isaac, who is still thinking about it
participants (2)
-
Isaac Jones -
Simon Marlow