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 SAA09331; Fri, 16 Apr 2004 18:07:16 +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 SAA08625 for ; Fri, 16 Apr 2004 18:07:15 +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 i3GG7DYM000552 for ; Fri, 16 Apr 2004 18:07:14 +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 17538341; Fri, 16 Apr 2004 09:07:13 -0700 Received: by tallman.kefka.frap.net (sSMTP sendmail emulation); Fri, 16 Apr 2004 09:06:18 -0700 Date: Fri, 16 Apr 2004 09:06:18 -0700 From: Kenneth Knowles To: "Brandon J. Van Every" Cc: caml Subject: Re: [Caml-list] build tools - good vs. fast, both cheap Message-ID: <20040416160618.GA27238@tallman.kefka.frap.net> References: <20040416011616.GA13198@tallman.kefka.frap.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 2004:99 brandon:99 labeling:01 offtopic:01 all-ocaml:01 focusing:01 admittedly:01 predictable:01 autoconf:01 motivations:01 monolithic:01 command-line:01 autoconf:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Thu, Apr 15, 2004 at 11:31:44PM -0700, Brandon J. Van Every wrote: > Ok, if you want to discuss, then let's please everybody refrain from > labeling other people's lines of discussion as offtopic rants, > uninteresting, etc. I agree, and apologize. It was a bit frustrating to hear the same thing over and over when I already agreed. > So where are we? We're having the age old engineering argument, "good, > fast, cheap, pick any two." We're all open source developers so we're > all cheap. :-) We've got one camp that sees an all-OCaml build + > package management system as the goal. Count me in on that, and I will > label it the "GOOD AND CHEAP" camp. We've got another camp that sees > getting any build + package management system together as quickly as > possible from readily available parts as the goal. I will label it the > "FAST AND CHEAP" camp. I think any good build process will make the creation of any package manager easier, so that's what I'm focusing on - admittedly steering the discussion that way whenever possible; I'm fairly confident in GODI, it just doesn't have what I personally need yet. As an example, Gentoo's ebuild scripts are highly specialized so that if you have a predictable autoconf package they need less than 10 lines - but they are capable of handling arbitrary commands. And on the build system side, I think that "FAST AND CHEAP" could evolve into "GOOD" one way or another as long as the motivations and design are sound. So, since development has already started on a number of tools that might be glued together, I'm most interested in critiquing not the tools but their approaches to the problem. These are the approaches I can see out there: (1) Monolithic automagical GNU Makefile (2) O'Caml script outputing make-agnostic Makefile (3) Command-line build-every-at-once ocaml tool (4) Roll your own Makefile, have the user edit it - often separated into a Makefile.config. (5) Use autoconf (why, oh why? it doesn't offer any O'Caml support) (6) Interscript? I don't really understand what it does and what the developer must do. My "plan" i.e. what I'm going to do eventually unless someone convinces me otherwise, is to try to plug (2) into an enhanced (3) and thus the whole build process will be in O'Caml. It won't address the needs of projects that have more than just O'Caml and C sources, but I already offered the following rationale: "It is easier to have many specialized build processes and glue them together than to have one catch-all" Anyone who is willing to write a build in a general purpose language should be more than willing to write glue in a general purpose language. If (6) can eliminate/reduce the work that I'm planning, then I'm still waiting to hear about it. Design time saves a lot more programming time than it wastes. > Makefiles and autoconf cannot achieve > that ultimate goal. I've worked with them plenty, back in the day I was > an autoconf guru. Now when I get back into it I just scream, "The > horror! The horror!" before I die. Me too; I still have old C and C++ projects that I never touch... I've yet to get a coherent response to my assertion that it is the implementation, not the concept that is wrong. (John provided an example in python which seems to imply he agrees that the concept is good) > So, with that in mind, what is currently the > most advanced build and package management system known to Humankind, in > any language? That is where we should be looking for design reuse. Do you truly disagree that these can be separated into two tasks? On the build side, I don't know of anything more advanced than automake/autoconf in design, though I hate their implementation choices. For package management, BSD, Gentoo, and Debian all have a model that is insufficient for O'Caml, and I think GODI is addressing the unique re-compilation needs. 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