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 SAA19454; Wed, 14 Apr 2004 18:50:51 +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 SAA19586 for ; Wed, 14 Apr 2004 18:50:50 +0200 (MET DST) Received: from calmail-cl.berkeley.edu (mailfarm.Berkeley.EDU [128.32.61.106]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i3EGomYM027301 for ; Wed, 14 Apr 2004 18:50:49 +0200 Received: from [64.162.212.212] (HELO tallman.kefka.frap.net) by calmail-cl.berkeley.edu (CommuniGate Pro SMTP 4.1.8) with SMTP id 16613951; Wed, 14 Apr 2004 09:50:48 -0700 Received: by tallman.kefka.frap.net (sSMTP sendmail emulation); Wed, 14 Apr 2004 09:49:57 -0700 Date: Wed, 14 Apr 2004 09:49:57 -0700 From: Kenneth Knowles To: skaller Cc: Nicolas Cannasse , "Brandon J. Van Every" , caml-list Subject: Re: [Caml-list] Re: GODI vs. Ocamake Message-ID: <20040414164957.GA24089@tallman.kefka.frap.net> References: <005e01c421f5$2dd45210$ef01a8c0@warp> <1081943666.20677.685.camel@pelican> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1081943666.20677.685.camel@pelican> User-Agent: Mutt/1.5.6i X-Miltered: at concorde by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; knowles:99 caml-list:01 ocamake:01 2004:99 model:01 autoconf:01 compile-time:01 autoconf:01 python:01 dependencies:01 beef:01 gnu's:01 affair:99 high-level:01 outputs:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk X-Status: X-Keywords: X-UID: 338 On Wed, Apr 14, 2004 at 09:54:27PM +1000, skaller wrote: > Yes. I agree with this model. The first order of the day > is to throw out make and replace it with a general purpose > language + a library which make writing program building > programs easier. I agree here that make is not the end-all of building. However, make is a language (shell) + a library (make itself). The real problem is the library is not written in the same language, and that both the language and the library suck. Re-implementing for different languages is a good idea. > To put this another way, I regard 'autoconf' as one > of the worst evils around. The correct solution is > a combination of Standards and a full scale programming > language -- not hacked up special purpose tools which > are so grossly inadequate they need yet *another* > tool to configure them .. and still don't work right. I disagree completely here. Autoconf is NOT a bunch of hacked up tools trying to fix each other, but rather a set of programming modules in a support library like you describe (albeit in weird languages). Even with a library to make writing program-building programs easier, it is a very intelligent division of modules: (1) Adjust to current system (2) Accept compile-time parameters (3) Build system (4) Install system (5) Package system (*) More; like unit tests etc. Autoconf *does* represent these modules, for the language of "shell/make/m4," with a target language of C. Both python and perl have similar module divisions (from my external users standpoint of having built modules for both). Basically, what you should not assert is that "make" is even *supposed* to perform any of the above except (3), or you are setting up a straw man. It is nicer when the language used in the build process is more powerful/safe than shell/make/m4. It is also nice for it to be the same as the target language, so no additional dependencies are introduced. You may have a beef with GNU's choices of implementation languages. Well I do too, but I'm not surprised. They also have a love affair with C, even for high-level stuff. I'm pretty sure we both agree that implementing the above modules in OCaml, for OCaml, is the best thing to do. OCamlConf kind-of sort-of completes (1) and (2) and then outputs a makefile that handles (3) through (5) pretty well. I would be ecstatic to have (3) through (5) written in ocaml, but haven't the time - thus my hope of possibly integrating ocamake or similar thing for (3). (4) and (5) are pretty trivial to do by hand. Just so I don't leave anyone out, I'd say both ocamake and OCamlMakefile handle (1) and (3) all at once. If ocamlconf+ocamake became "ocamlbuild" then I'd still keep the userland steps of: 1. Accept compile-time options and check system compatability. 2. Build desired items 3. Install desired items > [Interscript is a great python build tool] To your benefit, I assume that within Interscript, there is modularization, and it probably falls along similar lines. Indeed, this sounds like exactly a wonderful solution for python, but it is best for build and target language to be the same - firstly not to introduce dependencies and secondly so developers are immediately comfortable. Kenn ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners