RE: [Caml-list] Announcing the OMake build system version 0.9.1

["Brandon J. Van Every" <vanevery@indiegamedesign.com>]

Marcin 'Qrczak' Kowalczyk wrote:
>
> My makefiles generally include the following types of information:
>
> - Rules which tell "how to compile a *.foo file into a *.bar file"
>   and compiler options.
>
> - Variable definitions which gather sources from contents of
>   directories. It's usually "all files with a particular extension
>   from subdirectories, plus some additions which are generated,
>   minus some exceptions which are conditionally excluded".
>
> - Rules which tell which sources and commands to use for many-to-one
>   targets like programs and libraries, where source names are not
>   derived from target names automatically because there are many
>   sources.
>
> - Administrative rules for things like "make clean" and "make
> install".
>
> All this information is essential for building and impossible to infer
> automatically from other files. Another build tool can't eliminate the
> need of providing that information in some form. It can only provide a
> different language for expressing it.

'Language', by your definition, can include a GUI.  Under Visual Studio
2003, when doing C++ projects, the only one I definitely have to mess
with is 'make install'.  All the other jobs are common enough that I
simply don't have to worry about them.  Of course, I do have to
point-n-click, drag-n-drop to get my source files properly organized.

Of course, VS 2003 isn't pain free.  I do have to know where various
settings are located in the GUI, and it is definitely possible to put
settings in a 'wrong' or 'poorly architected' place.  It took me awhile
to go up this learning curve - but I put far more effort into GNU Make,
GNU Autoconf, and IMake, once upon a time.  It helps that I have a
grungy command line background, that I know this is really all that's
going on under the hood.  I view VS 2003 .sln files as 'just another
kind of Makefile', and they are usually amenable to hand editing.

You might argue that the 'language' is really in the .sln file, as it is
in a Makefile.  Well, the same can be said about Postscript, but end
users rarely manipulate Postscript directly.  They use tools, because
it's too complicated for most users to edit by hand.  So, part of the
dimension of this discussion, which seems to have the quality of "my
build tool is theoretically better than your tool," is how these things
behave as *TOOLS*.

One dimension of tool quality is how many people use the tool.  I hope
someone has some insight into my question about OCaml build tool
critical mass.

> And if I make small changes in one file in order to find some bug,
> it's essential to recompile only a few relevant files. How does it
> know which other files need to be rebuilt if it does not know *all*
> dependencies? Rebuilding everything is out of the question. It should
> take 7 seconds, not 7 minutes. And it does with make.

In 20..30 years, we will be using cheap, massively parallel computers
and exhaustively searching all the available options.  These issues will
go away.  In fact, *lots* of "how do I interface X and Y?" issues will
go away, we'll use brute force to glue all kinds of things together.
Meanwhile, if you've got enough hardware and a maintainable network,
maybe there's some distributed compilation thingamabob available
somewhere.  Of course, some problems are P-complete, but I'd hazard a
guess that trying different permutations in the hope that one is faster
in practice is not one of them.

> I can't say I like make, but any tool which requires to compile some
> files twice, or insists on recompiling everything after a
> local change, is not a viable alternative.

I'm sure there's probably a gradiated range of tradeoffs available for a
tool designer.  For instance, brute force could generate a provisional
dependency graph, then be reused some of the time, if not all of the
time.  That might actually work to speed things up most of the time.


Cheers,                         www.indiegamedesign.com
Brand*n Van Every               S*attle, WA

Praise Be to the caml-list Bayesian filter! It blesseth
my postings, it is evil crap!  evil crap!  Bigarray!
Unboxed overhead group!  Wondering!  chant chant chant...

Is my technical content showing?

// return an array of 100 packed tuples
temps
  int $[tvar0][2*100]; // what the c function needs
  value $[tvar1]; // one int
  value $[tvar2]; // one tuple
  int $[tvar3] // loop control var
oncePre
eachPre
  $[cvar0]=&($[tvar0][0]);
eachPost
  $[lvar0] = alloc(2*100, 0 /*NB: zero-tagged block*/ );
  for(int $[tvar3]=0;$[tvar3]<100;$[tvar3]++) {
    $[tvar2] = alloc_tuple(2);
    $[tvar1] = Val_int($[cvar0][0+2*$[tvar3]]);
    Store_field($[tvar2],0,$[tvar1]);
    $[tvar1] = Val_int($[cvar0][1]);
    Store_field($[tvar2],1,$[tvar1+2*$[tvar3]]);
    Array_store($[lvar0],$[tvar3],$[tvar0]);
  }
oncePost

-------------------
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