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