FW: Library infrastructure

[Seth Kurtzberg]

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 <m.p.donadio@ieee.org> wrote:

> 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