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 KAA31304; Mon, 6 Sep 2004 10:18:08 +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 KAA31317 for ; Mon, 6 Sep 2004 10:18:07 +0200 (MET DST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id i868I4pa013710 for ; Mon, 6 Sep 2004 10:18:06 +0200 Received: from [192.168.1.200] (ppp210-32.lns2.syd3.internode.on.net [203.122.210.32]) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i868Hx4Y090062; Mon, 6 Sep 2004 17:47:59 +0930 (CST) Subject: Re: [Caml-list] Announcing the OMake build system version 0.9.1 From: skaller Reply-To: skaller@users.sourceforge.net To: "chris.danx" Cc: David Brown , caml-list In-Reply-To: <413BAE8E.9020901@ntlworld.com> References: <4139ECD3.1050708@cs.caltech.edu> <001e01c492a6$872c7280$19b0e152@warp> <413A0921.7030607@ntlworld.com> <413A1E89.10806@libertysurf.fr> <1094361655.3352.476.camel@pelican.wigram> <20040905132006.GA15531@old.davidb.org> <413B2BCB.3030000@ntlworld.com> <1094399607.3352.679.camel@pelican.wigram> <413BAE8E.9020901@ntlworld.com> Content-Type: text/plain Message-Id: <1094458678.3352.980.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 06 Sep 2004 18:17:59 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 413C1D3C.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 sourceforge:01 2004:99 extensible:01 optimise:01 optimise:01 ocamlc:01 ocamlopt:01 tools':01 ideally:01 interfacing:01 generalised:01 model:01 generality:01 model:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Mon, 2004-09-06 at 10:25, chris.danx wrote: > You didn't specify the dependancies in the "build" system, but you did > in the files being compiled to some extent. Are you considering a > language aware or language neutral solution? Both: in the abstract, the system should be general, but it needs to be extensible to specialise for cases where optimisation is desired. Typically people optimise the 'inner loop' meaning if you spend much time developing code, you want good performance compiling things. If you spend much time running tests, you want to optimise that. For Felix, compilation is way faster than running the regression tests .. so I actually have optimisation in the form of dependency checking for the tests (to avoid rerunning slow tests that already passed). > > However if the source code contained enough information, > > the build scripts could be generated automatically. > > **That is what I want to happen** > > with the slight change that the program builds the actual program, > library, whatever. For the cases the tool is not designed for we can > rely on ocamlc/ocamlopt and the tools' semantics to cover it ourselves > if need be. Ideally developers would not have to deal with that case > but I'm not sure you can guarantee that when you're interfacing to other > languages, etc. Yes. My basic idea is that you need first generalised build semantics and optimisation model. Then you can tailor it, without sacrificing generality. If you start with a broken model like make, you just can't fix it. Make can't even handle trivial requrements such as unpacking a tarball. What's the target? Heck, you have to unpack the tarball to find what's in it. Even then, you have 200 targets, and one process that satisfies them all -- how do you code that in make? A typical trick is a dummy target -- GNU itself uses a file called TIMESTAMP I think, which is just a log file created as a side-effect of the process to represent the real set of 'targets'. Well that doesn't work when you have multiple processes with the common outputs .. interscript can tangle code files, or tangle code files AND weave documentation, so making documentation also makes code -- it would be silly to 'make code; make doc' since 'make doc' already satisfies the code target .. ugggg... G*d help you if you have complex recursive many-to-many processes -- its easier to just hand code your build process in some high level language than bother trying to represent it with make. -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net ------------------- 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