[CMake] Re: Raven, Antwrap, Buildr

[Brandon Van Every]

On Mon, Mar 3, 2008 at 9:13 AM, Gonzalo Garramuño
<ggarra at advancedsl.com.ar> wrote:
>
>  It is not the ruby syntax that is horrendous but the rake one.  I'm a
>  true fan of ruby but not of rake.   Raven is just a wrapper built on top
>  of rake to add java functionality

Ok, good to know.  I'm tempted to say that if it's easy to redefine
the syntax of a general purpose scripting language, that's
disadvantageous for a build system.  Although perhaps it's the same
level of concern as operator overloading in C++.  Yes you can do goofy
operator overloads, but they're actually useful if you're just trying
to do vector math instead of scalar math, or some kind of IO.  I
suppose operator overloads have to be weighed against the verbosity of
some_function_call(blah blah).  Perhaps a syntax can be well designed,
but the Rake author didn't happen to design it so well.  I do wonder
at programming cultures of redefining syntax though.  It might be
valid to say it's too easy in Ruby, or Lua.  There are certainly a lot
of language tweakers in the Lua community.

I imagine someone else will argue that redefining syntax is the killer
app that we're all needing for our large scale builds.  If only we
could customize to the way we personally think about a build.
Customization vs. standards, yep.  Maybe there's a whitepaper in that
somewhere, about why standards are better.

>  The advantage is for OO.  Consider this:
>
>  task :myexe { |t|
>        t.link_libs = "asdasd"
>        t.so_version = 1.0
>        t.call_func
>  }
>
>  With that, you'd basically have an OO approach to setting cmake
>  properties (and not just properties, you can also run a function defined
>  in whatever class t is).

Ok, an OO syntax that looks queer to a C++ programmer.  Not sure
that's a great marketing pitch, but maybe they'd come to love it
because it's OO.  It's worth noting that Lua isn't OO.  My jury is
still out on the technical merit of OO for builds.  I don't think the
Raven, Buildr universe proves anything, they don't seem to have any
projects big enough to warrant OO.  Onward to SCons.

>  > - how, in any universe, could this possibly be preferable to
>  > add_dependencies(target dep1 dep2 dep3...) ?
>  >
>
>  An api (say swig wrapped) that would be identical to cmake would look like;
>
>  add_dependency :target, :dep1, :dep2, :dep3

BTW I'm glad to see I'm not the only one who can't ever remember
whether it's singular or plural.  :-)

>  > Only Ruby people are going to see this syntax as an advantage.  It's
>  > worth remembering that Ruby got popular not because of the language,
>
>  No, ruby got popular with the language and is highly respected for it.
>  Rails made it popular for the web.

Perhaps we differ on notions of cause and effect.  IMO Python, Ruby,
and PHP all got popular because of the web.  Scripting languages get
tried when the code is throwaway and any scripting language would do.
A lot of web jobs were / are of that nature.  Haven't thought much
about why scripting languages are retained.  In Ruby's case, it
clearly has some advantages over Perl and is often described as an
OO-ified Perl.  In contrast, languages like Lisp and Scheme are never
retained, even though plenty of scripted versions exist.  Scheme could
be dismissed as too non-standard; even now the Scheme world is split
between RSR5, RSR6, and everyone's personal variant.  Common Lisp,
they claim it's all about historical prejudice due to the AI Winter,
but how long can that chestnut remain true when a new generation of
programmers doesn't even know what the AI winter was?  Maybe it's
their inability to define a standard C FFI.  Well, TIOBE would seem to
say that Common Lisp is more popular than Lua, so indeed maybe old
prejudices are fading.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

>  P.S.  BTW, rake is something like a 200 line script only, so it is
>  extremely bare-bones.

Hm.  A reputation disproportionate to its size.  How does a language
or tool manage that?  Early niches filled?


Cheers,
Brandon Van Every