-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings! For those interested in the LibraryInfrastructure project, I'd like you to take a look at some example source code I wrote (about 650 not completely beautiful lines) for a haskell-based build and install system: http://www.syntaxpolice.org/tmp/DistUtils-0.0.1.tgz BTW, I'm taking suggestions for the name of this project / module. This is a basic prototype for my vision of a pure haskell based system for building, installing, & packaging pure haskell stuff (like hunit, which is included as an example). This system will, in the future, act as a wrapper around a more complex build system (there are two such systems in the works). Hopefully "DistUtils" can provide extra targets, like bdist-deb, to such systems for free. What it does now is build stuff for ghc and make a distribution for Hugs. It can create a packages.conf file for ghc registration, and does something funny for hugs registration (see the README). I promise I'll make it do something for nhc soon. Commands for this version include "sdist" for a tarball, "install-hugs", "install-ghc", "register-ghc" etc. The library author will only have to provide information like [1], and DistUtils will do the rest. The module hierarchy is not exactly what I _want_ it to be. I really envision something more like [2]. I also envision the "ToolInfo" module to be merged with Ghc's Package module and hugs and nhc be made to use it (perhaps nhc already does). DistUtils also provides a means by which applications can easily add an --toolinfo flag so that other tools can interrogate executable programs (see the Example example). So in the long term, I see DistUtils as a module to each of the Haskell Implementations, including whatever /usr/bin/haskell is. Users can run ./Setup.lhs which will ask the compilers about themselves (or read packages.conf to get information about the compilers or maybe it'll use autoconf or something), then create possible targets based on the compilers and versions of available tools. Peter Simons seems to have a lot of ideas for building Haskell code, and some stuff can definitely be taken from HMake. Right now we just do some simple stuff. peace, isaac [1] - -- Setup.hs module Main where import DistUtils.Core import DistUtils.ToolInfo toolInfo = (basicPackage (OtherTool "DistUtils") (Version 0 0 1)) {haskellSources= map ("DistUtils/" ++) ["Info.hs", "Core.hs", "Compilers.hs", "ToolInfo.hs", "GhcPackage.hs" ], haskellMainMods=["Setup.lhs"], docs =["etc", "hugsWrap", "examples", "README"] } main :: IO () main = distUtilsMain toolInfo - ------------------------------------------------------------ [2] .distributionMain :: ToolInfo -> IO () -- implements standard functionality /Package .SystemConfig { installedPackages :: [Package], installedCompilers :: [Compiler], defaultCompiler :: Compiler } .getSystemConfig :: IO SystemConfig .defaultFlags (like --toolInfo) .emptyPackage .Package {depends :: [Package], buildDepends :: [Package], } .depends :: [Package] -> Graph Package .buildDepends :: [Package] -> Graph Package /Compiler .installedCompilers :: [Compiler] .defaultCompiler :: Compiler /Compilation .dependancies :: [HaskellModule] -> Graph HaskellModule .build :: Package -> Compiler -> IO () /Installation .install :: Package -> Compiler -> IO () .register :: Package -> Compiler -> IO () .export :: Package -> IO () --put the sources somewhere .sourceDist :: Package -> IO () -- make a tarball -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iD8DBQE/FGV/BLPTZ7K4MaIRAoB0AKCraBFr9IGzyF3329oCY3oeX7VZaQCfTxlV 6D1zX9yhNsk/TUIza3h3H3w= =lj7M -----END PGP SIGNATURE-----
On Tue, Jul 15, 2003 at 04:35:11PM -0400, Isaac Jones wrote:
For those interested in the LibraryInfrastructure project, I'd like you to take a look at some example source code I wrote (about 650 not completely beautiful lines) for a haskell-based build and install system: http://www.syntaxpolice.org/tmp/DistUtils-0.0.1.tgz [...] What it does now is build stuff for ghc and make a distribution for Hugs. It can create a packages.conf file for ghc registration, and does something funny for hugs registration (see the README).
The CVS version of Hugs has a simpler mechanism than you're assuming here: a path entry of the form /path/to/dir/* means all immediate subdirectories of /path/to/dir. As far as Hugs is concerned, I'm a bit confused. There seem to be three ways a Haskell package can be installed on a system: - installed using the system (e.g. Debian) package manager - installed by the local administrator in /usr/local (or the equivalent) - installed by users in their home directories The last two will want to keep packages separate for easy deletion and replacement, but it seems wasteful for the first to do so, since the system package manager keeps track of which files belong to which package.
Remember that the code I posted is really just to facilitate
discussion at this point. I'll try to write up a better summary of it
soon. See the bottom of this email for a little more info.
Ross Paterson
The CVS version of Hugs has a simpler mechanism than you're assuming here: a path entry of the form /path/to/dir/* means all immediate subdirectories of /path/to/dir.
That is fine; the hugsWrap script is just included as an example. I wanted to be able to do _something_ for hugs. Either way works fine assuming that hugs can be built with a nice set of default paths to look in, including one in the home directory?
As far as Hugs is concerned, I'm a bit confused. There seem to be three ways a Haskell package can be installed on a system:
- installed using the system (e.g. Debian) package manager - installed by the local administrator in /usr/local (or the equivalent) - installed by users in their home directories
The last two will want to keep packages separate for easy deletion and replacement, but it seems wasteful for the first to do so, since the system package manager keeps track of which files belong to which package.
Indeed. My example system could work in a few ways. debian/rules basically wraps something like: Setup.lhs install-hugs --prefix=debian/tmp --runfrom=/path/to/hugs/extentions --noregister Which can stick stuff anywhere below extentions and as you say, the package manager can worry about deleting them when stuff is removed. The --noregister is nonsensical with the way CVS Hugs works, but other than that, this would be the same. (debian/rules is itself wrapped by "./Setup.lhs bdist-deb") OTOH, the user could say: Setup.lhs install-hugs --prefix=~/path/that/hugs/knows/about And the sysadmin could say: Setup.lhs install-hugs --prefix=/usr/local/path/that/hugs/knows/about The former doesn't work with the basic package registration stuff that I included since it wants to write to /etc/hugs/includes. SimonPJ suggested that I clarify this a bit for people who haven't been following the discussion closely. I hope to put together a lot more information over the next few weeks, but to give you an idea of the use-cases for this tool: End User: - Installs packages with a package system like rpm (basic version works can create debian files, at least on my computer ;) ) - or can run "./Setup.lhs install ghc" to build, install, and register a ghc version of the program (basic version works) Packager: - Can run "./Setup.lhs bdist-deb" to build a skeleton debian package for the system for each of the installed compilers. (this already sorta works!) 3rd Party Author: - Writes a Setup.lhs program, which imports DistUtils.Core (or something) that does most of the hard work. If they have rather simple needs, like hunit, they only really have to include the name of the program, the version, and the names of the source files, and call DistUtils.defaultMain or something. (basically works) - If they have a more complex program, then DistUtils could produce some Makefiles for the project based on the GNU Make systems already underway, or perhaps just some skeleton makefiles for them to fill in. - If they don't want to change make systems, then they can write their own Setup.lhs scripts to wrap their build system to conform to the standard targets, hopefully this will allow targets like bdist-deb to "just work" nomatter the build system. Compiler Authors: - Conform to any changing package management system (can probably wait a while) - may include writing functionality so the compiler can be asked questions about itself - may include altering compilers to read /etc/haskellPackages.conf or something to find out about which packages are installed or where to look for imports. - Include "DistUtils" module with compiler (in exchange, we can hopefully remove some stuff thats getting included with the compilers now) Random Haskell Programmer: - Can use the DistUtils _library_ as a means to create further tools to download, build, install, etc. For instance we might have a function which figures out the dependancies among haskell modules, another function which returns a list of the installed packages. peace, isaac
participants (2)
-
Isaac Jones -
Ross Paterson