Re: [Caml-list] build tools - good vs. fast, both cheap

[Kenneth Knowles <kknowles@berkeley.edu>]

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