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

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

Richard Jones wrote:
>
> Can I stand up for 'make' (well, GNU make anyway) and point out
> that whatever its philosophical problems, it:
>
> (a) works

As per discussion, YMMV.

> (b) works on lots of different platforms, including Windows

Um, sorta.  Getting a GNU Make that is bug-free, up-to-date, and plays
well with MSVC is more problematic than you'd think.  Well at least, I
ran around and around in circles about it for awhile.  Somewhere somehow
I came up with a valid one, and I'm not sure where I got it.  There are
some longstanding bugs pertaining to Windows that are still extant in
the GNU source code, that they're not resolving "because it's not enough
to make another release out of."  This has been true for a few years.
Other people have made patches, but these don't get incorporated into
canonical builds and aren't readily distributed anywhere.

It is more accurate to say that GNU Make works fine in a Cygwin / Mingw
environment.  That isn't really Windows, it's UNIX viralling into
Windows.

Many projects also orient themselves towards GNU Autoconf, which again
is problematic in a pure MSVC environment.  One of these days I may port
Autoconf to MSVC, or track down someone else's effort.  Last time I
looked at that problem, I failed to get it done.  It didn't look like
such an easy problem, because m4 wasn't so easy to move over.  But,
solving *that* problem would be preferrable to going through the same
UNIX dependency-and-elimination headaches one has to do anytime one
moves a project from Cygwin / Mingw to MSVC.  At least if Autoconf
worked in the pure MSVC enviornment and targetted the right header
files, you'd know how much of the Cygwin / Mingw project isn't portable.
Then you could decide if it's trivial to eliminate UNIX dependencies, a
lot of work, or impossible.

So if someone came up with an OCaml-centric build tool that resolved
configuration dependencies, was written in OCaml, worked well under all
platforms including *native* Windows, and lotsa people used it, I'd be
DAMN HAPPY.

I think the Python community is strengthened in this regard.  Seemingly
they can run their stuff on all the platforms, they really don't have to
care much at all which platform it's on.  Getting OCaml to the point
where it's really platform neutral is a worthy goal.  I don't see GNU
Make as part of that goal.  I see it as a stepping stone that many of us
would like to step over already, for all of our various reasons.

> (c) works with lots of different languages (except Java, but that's
>     Java's fault), including our favorite OCaml, and

Agreed.

> (d) is familiar and simple to use for most developers

Gimme a break.  I put a *HUGE* learning curve into GNU Make, once upon a
time.  It's not simple, it's just familiar to a lot of UNIXen.  Ok, it's
simple for trivially sized projects.  When you start getting into
multiple directories, auto-generating dependencies, and keeping debug
vs. release builds separated from one another, you end up doing tons of
manual labor that IDEs like Visual Studio simply solve.

> Sorry, just had to point out that sometimes the perfect tool fails for
> practical reasons.

Yes, again see my question on critical mass.


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