Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] construction, packaging and distribution tools
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: j h woodyatt <jhwoodyatt@m...>
Subject: [Caml-list] construction, packaging and distribution tools
everyone--

I have some experience with the subject of this thread.  I have 
contributed to the CPAN, and I was once charged with managing the 
dependency of an enterprise software system on packages obtained from 
the CPAN.  The subject is an interesting one.

I will begin by observing that the success achieved by the CPAN is due 
in large part to the enormously complex layer of scriptology used to 
construct Perl itself on such a wide variety of platforms.

First, while the perl interpreter isn't actually written in Perl, an 
awful lot of the code that constructs the perl distribution is written 
in Perl.  (That code lives in a collection of Perl core library modules 
with 'MM_' in their names.)

What they are essentially doing is using the traditional C construction 
tools, i.e. /usr/bin/make and the like, to get a bootstrap version of 
the Perl interpreter compiled (this is called 'miniperl'), then they use 
miniperl to execute the rest of the construction required to build the 
entire distribution.

It was a fairly trivial step from there to take the code that 
constructed the Perl core library and press it into service compiling 
contributed extension modules.  All that code is written in mostly 
portable Perl that refers back to a special module in the core library 
named Config.pm, which defines a huge array of configuration variables 
whose values were discovered when the ./Configure script executed at the 
start of the construction process.

That said, one of my hobby projects last year was to write a tool that 
would allow me to write portable software construction scriptology in 
Perl and bypass the menagerie of weird /usr/bin/make implementations 
that one finds all over the place.  The code I wrote is called "Conjury" 
and the version in the CPAN right now is not the most up-to-date, but 
it's a good start.

One other observation is how Java project construction is often done.  A 
lot of the complexity of constructing distributions of pure Java code is 
managed by the tools distributed in the Java development kit.  The 
compiler, linker and archiver are all pretty good about managing 
dependency chains.

Very complicated projects with many phases and very deep dependency 
chains, e.g. Tomcat servlet container, often use a tool called Ant 
developed by the Apache Foundation.

Ant allows you to write your construction scripts as XML documents, and 
you can extend the functions available in those scripts by writing Java 
classes and loading them during the construction process.

As it stands today, the Objective Caml distribution could use more work 
before it would compare well to what either Perl or Java programmers are 
used to seeing.  I humbly suggest if there is a debate on the merits of 
which design pattern to employ for packaging and distribution, some 
attention should also be paid to the construction process.

Very large software development efforts rarely use construction systems 
based on /usr/bin/make without treating the Makefile files as 
"intermediate" construction products.  Both Perl and the Linux kernel 
are fairly typical examples of this.

Perhaps there is a need for a tool in the Objective Caml distribution 
that "closes the construction, packaging, and distribution loop" in a 
clean and consistent way across all platforms.

(It would be an extra bonus if I could use that tool to write 
construction scripts for Mac OS X application bundles, but I'll use what 
there is until there is something better.)


--
j h woodyatt <jhw@wetware.com>
"You're standing on sacred ground.  Many strange and wonderful
things have transpired right where you're standing."
                                               --unattributable
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr