From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id FAA19408; Fri, 24 Aug 2001 05:59:20 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id FAA19366 for ; Fri, 24 Aug 2001 05:59:18 +0200 (MET DST) Received: from smtpout.mac.com (smtpout.mac.com [204.179.120.89]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f7O3xHj18592 for ; Fri, 24 Aug 2001 05:59:17 +0200 (MET DST) Received: by smtpout.mac.com; Thu, 23 Aug 2001 20:56:44 -0700 (PDT) Message-Id: <200108240356.UAA29430@smtpout.mac.com> Received: from asmtp01.mac.com ([10.13.10.65]) by smtp-relay01.mac.com (Netscape Messaging Server 4.15 relay01 Jun 21 2001 23:53:48) with ESMTP id GIK0AJ00.9LW for ; Thu, 23 Aug 2001 20:56:43 -0700 Received: from localhost ([17.206.25.144]) by asmtp01.mac.com (Netscape Messaging Server 4.15 asmtp01 Jun 21 2001 23:53:48) with ESMTP id GIK0AJ00.GMJ for ; Thu, 23 Aug 2001 20:56:43 -0700 Date: Thu, 23 Aug 2001 20:56:42 -0700 Reply-To: jhw@wetware.com Content-Type: text/plain; format=flowed; charset=us-ascii X-Mailer: Apple Mail (2.388) From: j h woodyatt To: caml-list@inria.fr Mime-Version: 1.0 (Apple Message framework v388) Content-Transfer-Encoding: 7bit Subject: [Caml-list] construction, packaging and distribution tools Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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 "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