Something In the Make [UPDATED]

Bil Kleb mentioned on the ruby-talk maillist a post by Martin Fowler where Martin shares his belief that build tools must be powerful, and that certain build tools that use a declarative xml syntax as a Makefile language (like Ant) sometimes come short of that goal, or are just not flexible enough.

Of the tools you will find in my purse (toolset for geekettes) the build system is among the most important ones. You have to be picky with whatever you carry in your toolset.

For example, I never totally favored GNU autotools, and even some of its proponents concede that some things have become not as pretty as they should be, which ends up getting in your way. ( I mean, there’s a book for every little gear autotools has to offer, easy it is not)

As a result I only use the GNU build system when:

1) I have no choice but using it (too often, when building free software someone else wrote)

2) There’s no 2, I only use it when I am hard pressed to use it, I love free software really, but autotools is more like a free nightmare.

And in contrast this is the beautiful thing about Rake (ranked high in my purse-ware) it does everything it has to do in a well-defined, simple language, it’s powerful and easy to learn and it’s built on top of Ruby as a DSL. Applause for Mr. Weirich. (Rake’s author). All true rubyists use Rake for a reason.

So I think Mr. Fowler is right, and so is Matt Foemmel in his quest for a better build system, using JRuby plus a Rake port that runs on top of JRuby, what he calls “JRake”. (was “Jake” already taken ? :-)

Foemmel is not alone, for people feeling groovy, Ant scripting is Godsend. (GRake !)

Which approach is to be favored ? Still too early to say, but the confluence of Java and Ruby is probably one of the most interesting things to watch in the near future. (hopefully, a whole lot more of practical purse-ware for me to use, as a result of this cross-pollination)

Update: Some colleagues are blogging and tracking build tools closely: Aslak Hellesøy reviews Raven, JRake and Antbuilder, Rob Thornton at InfoQ analyzes JRake in more detail. They forgot to mention the Groovy approach though, even if Groovy it’s not strictly Ruby some may find it a good match for their current work environment.


12 Responses to “Something In the Make [UPDATED]”

  1. 1 Ricky Clarkson December 19, 2006 at 1:37 am

    A relatively new project, Gosling, allows you to write your build in Java:

  2. 2 umageller December 19, 2006 at 2:07 am

    Thanks for the link, Ricky.
    So there goes a third scriptable java build system to review !

  3. 3 mriou December 19, 2006 at 2:08 am

    You might also be interested in Raven ( It’s somewhat close to what Matt Foemel is doing (Rake with some Java primitives) and adds some Ruby Gems for dependency management.

    I’ve kept it pure Ruby for now and it works with JRuby. Check it out if you have some time.

  4. 4 umageller December 19, 2006 at 3:02 am

    ummmm… attempted to gem install rake, then gem install raven and I get a 404 error. (ruby 1.8.4, openSuse 10.1, Linux 2.6.16)

    …………… output ————————-
    Successfully installed rake-0.7.1
    Installing ri documentation for rake-0.7.1…
    Installing RDoc documentation for rake-0.7.1…

    dbext:umagella # gem install raven
    ERROR: While executing gem … (OpenURI::HTTPError)
    404 Not Found

    maybe it doesn’t find the download url you declared in the gemspec ?

  5. 5 Sachin December 21, 2006 at 1:18 pm

    Wait for few more days, Eclipse and all leading IDEs will have your said feature included. Now JDK6 comes with Ruby, JavaScript support and a build tool integration is indeed for all types of artifacts.

    By the way, have you tried Maven to configure for Java + Ruby projects?

  6. 6 Eugen Minciu December 21, 2006 at 6:16 pm

    Of course, there scons at It’s written in Python and oriented towards C/C++ development. I haven’t used it in a long time but it was decent at the time I used it (maybe three years ago, I don’t recall exactly)

    You didn’t mention what I think is another big problem for the GNU autotools. Things like the ./configure scripts are horrifically slow.

  7. 7 Ulluru December 26, 2006 at 10:15 pm

    I am having serious doubts about using ruby for anything these days. It is excellent for productivity, yes, but any language that chews up 60% of my cpu time as it runs a simple script is just not paying attention to the world.

    I can’t believe people keep talking about all these cool tools, yet don’t even partially flinch at the excruciatingly slow execution speeds that Ruby has to offer. Rake is a great tool, but most tools which have to deal with any serious amount of data are just too slow to be used without the “ugliness” of C being introduced anyways.

  8. 8 Uma December 27, 2006 at 2:00 am

    Ulluru: All publications, newspapers, books, even blogs have a target audience. You don’t seem to fall within the boundaries of this audience: leading edge Ruby programmers. As you can see from the text, what I talk about is mostly about Ruby implementations,
    coverage, identification and reporting of interesting/disruptive trends mainly about Ruby.

    It’s okay if you don’t fall within the boundaries of this target public, I wouldn’t dare to suggest you should change that, I just can’t see the reason why you’re not posting in some other blog about the other 40% of the programming languages you are fond of, or start a blog, I will surely read it with great pleasure.

    I don’t agree that any non-trivial codebase eventually becomes spaghetti code, you are implying and extrapolating too much from possibly not the best data sample

    Another thing: I am among the tiny group of people who really care about performance, so you really have chosen the wrong person to nag, I will be reporting soon (as Pat Eyler has done) about the state of the art in Ruby implementations.
    I dare to predict you will have to erase that commonplace notion (Ruby = slow), hopefully in 1 or 2 years from now.

  9. 9 Ulluru December 27, 2006 at 3:19 pm

    I can’t wait till YARV or whatever will bridge that gap. Don’t get me wrong by way of my O.T. comment. I like rake. I am just a bit frustrated by all this effort being concentrated on all these great tools being created when you can’t really use them for large data sets. I just play with

    If I have to use ruby as glue with data crunching in the RDBMS/Warehouse back-end then sure, but then we’re back to square one. That one’s been flogged to death already so my apologies for bringing it up again.

    I would love to see Ruby (my Favorite) at least as fast as Lua (not my favorite) I think Matz’ “bikeshed” comment extends to this part of Ruby as well. I am not a compiler/VM expert (I’m not even a proper Rubyist)and most Rubyists aren’t , This is why we see a lot of tools being created _in_ Ruby, but not significant improvements in Ruby’s speed which requires a lower level understanding of compilers/interpreters etc. (I hate to say this because it is going to start a flamewar)

    Even the speed-up initiatives are sort of staying within the “familiar” which is to try to write something in Ruby or in Java. Again, I’m not a compiler expert (did a toy one during comp-sci days) but from a lay person’s perspective, if we are going to go through the trouble of x-lating Ruby to JVM bytecodes, why not just do it for the X86? or why not a proper Ruby compiler for the X86 instruction set? I don’t think Ruby is just so exotic that it’s idioms cannot be translated to a compiled paradigm.

    It would be nice to know that when you’re done prototyping, you can always compile it and benefit from a much higher speed boost. I’d like that solution even better than the whole byte-code thingy because VM’s just bother me for some reason.

    My simplistic conclusion is that there just aren’t that many domain experts (Matz, ko1 and maybe a few others) in the Ruby community. So, everyone keeps building the cool bikeshed using ruby, but very few (Koichi etc.) look at the reactor next door

    I am really looking forward to your prediction becoming true re: Ruby and its execution speeds and hope my nagging is proven wrong. Sometimes, it is good to be wrong :)

  10. 10 umageller December 28, 2006 at 4:24 pm

    Thanks Ulluru for joining the conversation, hope my comment didn’t come across too harshly.

    I’m watching with interest the state of the art of all implementations, not just the MRI. (or YARV, for that matter, which is currently being merged with MRI, so eventually the MRI *will be* YARV, as _why reports: )
    Rubinius and XRuby are very interesting projects to watch, and as I said elsewhere, the Ruby implementation(s) that run atop the JVM are very welcome as a counterbalance for the crop of other implementations that run on the .NET CLR.
    Will the Ruby+JVM implementations be the faster and better performant ? Too soon to say.

    My take is that VMs more Smalltalk-ish or more Self-ish have better chances to succeed in the performance deparment. The JVM, very obviously, has the advantage of widespread deployment, and binary lingua franca, but I don’t discount we shall see the day when Ruby is also used as a systems language for certain tasks where you would have used C++ in the past.
    A girl can only dream so much :-)

  11. 11 Ulluru January 1, 2007 at 6:02 pm

    No worries, I should keep my comments on topic. I’m loving the new YARV benchmarks though. This is really an awesome new year’s present!


  12. 12 Uma January 1, 2007 at 6:59 pm

    by the way… _why is posting this, as we speak…

    speedup charts and all…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Time Travel


December 2006
    Apr »

%d bloggers like this: