Some comments,
The BSD ports system:
1. Is intended for a completely different purpose and
2. Has far too many bugs and problems.
On #2, I occasionally talk to people who say that the FBSD ports system works for them, but my own experience, and the experience of most of the people I've talked to about it, is that the quality is very variable and many packages simply refuse to install. I did a quick test here and had problems with about 20% of the packages I tried. Other similar systems such as the ports for Net and OpenBSD and emerge all have problems, in varying degrees but in my mind excessive.
Going back to #1, the purpose of systems like BSD ports is to handle the downloading, installation, build, and configuration of packages for an operating system. How much of this is relevant to a language library?
One primary purpose of these systems is to make it possible for less sophisticated users to install and use O/S packages. This certainly does not apply to users of a complex language such as Haskell, and those in the Haskell development community are not novices who need black box tools to hide the complexity of the software infrastructure.
By including automatic downloading, these systems seriously restrict your options as to format and configuration of download sites. I think that is a restriction that is unwise for the situation under discussion.
I most certainly do _not_ want a tool that I invoke to install a library to, on the basis of automated dependencies, update other libraries to a later version (or, worse, downgrade to an earlier version).
On Tue, 22 Apr 2003 13:05:43 -0400
Matthew Donadio
Tanton Gibbs wrote:
Don't forget three others: CPAN, CTAN, and SourceForge
Yes, they are nice, but they dosn't totally solve the building process (though I could be worng about CPAN; I try to ignore perl :) ). The ports tree handles this.
For those unfamiliar with the BSD ports tree, here is how it would be handled in the Haskell world.
You would have a set of directories in the same tree, lets say /usr/haskell/
Libraries would live in this tree, and you would group them into rough categories.
There would also be a directory with Makefile includes.
Each library would include a Makefile to build the library. These Makefiles only define download sites, dependencies, tool requirements, and limitations. They include other Makefiles to do the real work.
There would probably be ghc.mk, nhc.mk, and hugs.mk with compiler specific things, and also hdoc.mk, haddock.mk, etc, for tools. There would be a master Makefile that would detect which compilers are installed, and build library versions for each. This master makefile would also handle tasks like downloading the source, applying patches, etc.
In the BSD world, this works very well. You can install the minimal OS on a machine, cd to /usr/ports/editors/AbiWord2, type make install, and have it download, build, and install _everything_ needed (GNU make, X11, Gnome, etc) to build AbiWord for Gnome2.
Maybe I will create a quick mock up.
Another way to do this is to standardize a library format (analygous to Java JARs), and to extend the build process in hmake (or create a hlibtool), so you could do something like
hmake -ghc -installlib http://some.site/some/path/somelib.tar.gz
To automate everything.
Just some caffine inspired thoughts...
-- Matthew Donadio (m.p.donadio@ieee.org) _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
-- Seth Kurtzberg MIS Corp 480-661-1849 seth@cql.com