FW: Library infrastructure

[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)