[CMake] Java, Ant, JRuby, and JRake

[Brandon Van Every]

http://martinfowler.com/bliki/JRake.html

"Now that JRuby is getting more and more mature, several people are
thinking of finally doing something to improve the world of build
scripts by replacing ant with rake.

My former colleague Matt Foemmel has starting doing this for real and
is writing up progress on his FoemBlog. Matt's written more build
scripts than most and around 2000 we both made the mistake of thinking
an XML based build file was the way to go. We also both now believe
you need a full scripting language.

The thing with build scripts is that you need both declarative and
procedural qualities. The heart of a build file is defining tasks and
the dependencies between them. This is the declarative part, and is
where tools like ant and make excel. The trouble is that as builds get
more complex these structures aren't enough. You begin to need
conditional logic; in particular you need the ability to define your
own abstractions. (See my rake article for examples.)

Rake's strength is that it gives you both of these. It provides a
simple declarative syntax to define tasks and dependencies, but
because this syntax is an internal DomainSpecificLanguage, you can
seamlessly weave in the full power of Ruby."

Well, CMake certainly allows for conditional logic.  I've even proven
that you can use CMake script for "inappropriate" tasks like GNU
Autoconf + GMake translation.  :-)  Really, all that's needed to do
that, is variables + conditional logic + a regex engine.  The
question, of course, is whether people want to learn CMake script, use
a scripting language they already know, or use a scripting language
they have less of an objection to learning.  This isn't really about
OO per se.  This is about the learning curve of Yet Another Scripting
Language, and strategies for reducing that learning curve.  As I've
noted before, superior documentation and tutorial technologies is a
completely different way to tackle the problem.

http://www.martinfowler.com/articles/rake.html#UsingRakeToBuildNon-rubyApplications

"Although I've not done this personally we have had some experience of
using ruby as a build language on one of our bigger Java projects. The
build got to a point where it was painful to script it using ant, so
we ended up building a custom build system in ruby. It worked out
rather well, and it's certainly an option we would use again for more
complex projects. One the reasons we liked it was because having a
full (and malleable) language allowed us to describe the build in the
terminology used by developers: tiers, modules, jars, ears. It also
ended up being a good bit faster."

CMake CVS currently has some "sorta OO" capabilities.  It has
Properties, which can be applied to the following "scope_values":
GLOBAL, DIRECTORY, TARGET, SOURCE_FILE, or TEST.  A "scope_value"
could be viewed as a synonym for a Class; CMake CVS currently has 6
hardwired classes available.   What is lacking, however, is a way for
the user to define his own classes.  Maybe this isn't needed.  Maybe
CMake will simply add new hardwired classes as the need for them
becomes apparent.  But, maybe this won't be fast enough for people's
custom / vertical applications.

I think it is important to monitor the "Ruby building Java" trend.

I would note, however, that http://www.ohloh.net/projects/747?p=Rake
puts Rake as a 1 person-year project.  Not sure about JRake, which
runs on JRuby.  I've also noticed that some language communities, like
Ruby, generally don't need to compile stuff.  The following article
explains to the Ruby community why Rake even exists.
http://www.railsenvy.com/2007/6/11/ruby-on-rails-rake-tutorial
Strategically, it is possible that language communities like Ruby will
never produce industrial quality build tools, because there simply
aren't enough Ruby programmers who need to compile something.  So the
use of Ruby to solve build problems, will depend upon Ruby living
symbiotically with other languages that do need to be compiled (C/C++,
Java, C#).


Cheers,
Brandon Van Every