[ANN] Rant 0.3.2

[Stefan Lang]

Rant is a flexible build tool written entirely in Ruby,
similar to Rake.

== What's new in this release?

* Rant aids you in splitting up your buildfiles and placing them in
multiple directories.
* Bugfixes.

== More about Rant

The equivalent to a Makefile for make is the Rantfile. An
Rantfile is actually a valid Ruby script that is read by the
rant command.

Rant currently features:
* Defining custom tasks
* Automated packaging, testing and RDoc generation for Ruby
applications and libraries.
* Primitive support for compiling C# sources portably with csc, cscc
and mcs.
* A configure plugin for easy environment and build-parameter
checking (but not like autoconf!) which saves data in a yaml file.
* The rant-import command creates a monolithic rant script,
so you don't depend on an rant installation anymore.

As programmers usually want to see code, here is a short and very
basic example of rant usage:

A file called Rantfile contains the code:

file "backup/data" => "data" do |t|
sys.cp "data", t.name
end

Running rant in the directory of this file:

% rant
cp data backup/data

will ensure that the "data" file in the "backup" directory is up to
date.

== Installing Rant

You can install Rant as a RubyGem:
% gem install -r rant

or download the package from RubyForge(http://rubyforge.org/frs/?group_id=615)
and install with setup.rb:
% ruby setup.rb

== Resources

Current docs:: http://make.rubyforge.org
Rubyforge page:: http://rubyforge.org/projects/make/

 

[Jamis Buck]

Rant is a flexible build tool written entirely in Ruby,
similar to Rake.

Could you expand on that a little bit more? What are some of the
differences between Rake and Rant? From the name it sounds like the
relationship might be "Rake is to Make as Rant is to Ant", but that's
just a shot in the dark.

- Jamis

 

[Stefan Lang]

Could you expand on that a little bit more? What are some of the
differences between Rake and Rant? From the name it sounds like the
relationship might be "Rake is to Make as Rant is to Ant", but that's
just a shot in the dark.

- Jamis

During development I use the following build tools as reference:
* Ant (Java)
* Nant (C#)
* make
* SCons (Python)
* Rake

Since the name Rake was already taken, I choose Rant.
(Although Rant perhaps sounds a bit "ambiguous" to (native) English
speakers

WRT comparison with Rake: I replied to a post of Florian Gross in
which i explained some differences between Rake and Rant. Just
look for the header "Re: [ANN] First release of Rant". If you like,
I can send you the relevant email.
Anyway a short list of differences here:

Since the last release, Rant lets you define subdirectories:

file "prog" => "src/main.o" do
# puts some actions here
end
subdirs "src", "doc"

Now Rant will look for a task "main.o" in an Rantfile in "src/".
src/Rantfile could contain:

file "main.o" => "main.c" do
# compile main.c to main.o
end

A short Rantfile for your Ruby application could look like:

import %w(rubytest rubydoc rubypackage)

lib_files = Dir["lib/**/*.rb"]
dist_files = lib_files + %w(Rantfile README) + Dir["{test,bin}/*"]

desc "Run unit tests."
gen RubyTest do |t|
t.test_dir = "test"
t.pattern = "tc_*.rb"
end

desc "Generate html documentation."
gen RubyDoc do |t|
t.opts = %w(--title wgrep --main README README)
end

desc "Create packages."
gen RubyPackage, :wgrep do |t|
t.version "1.0.0"
t.summary "Simple grep program."
t.files dist_files
t.bindir "bin"
t.executable "wgrep"
t.package_task
end

task :clean do
sys.rm_rf %w(doc packages)
end

With this Rantfile, rant runs unit tests, RDoc, creates tar.gz, zip
and gem packages and provides the "clean" task.

We use +import+ in this file, which does a similar thing as require.
But it allows the following:
% rant-import --auto ant
And now you have an Rant script in the file "ant" which makes your project
independent from an Rant installation. Just run:
% ruby ant

You can define tasks and run Rant from irb, use it as a library or
invoke your Rantfile directly. Although it looks like Rant would
introduce methods in the global namespace, it doesn't. Methods of
the FileUtils module can be called through the +sys+ method.

Besides that, Rant provides (primitive) support for C# and a "Configure"
plugin.

I recommend to read the Rant documentation at http://make.rubyforge.org/.

Stefan

 

[Lionel Thiry]

Stefan Lang a écrit :

During development I use the following build tools as reference:
* Ant (Java)

Following your code samples, I must tell I feel it hard to see where Rant is
affiliated with Ant.

* Nant (C#)
* make
* SCons (Python)

I'm really curious here: what have you borrowed from SCons? Does Rant use a
directed acyclic graph for managing file dependencies? (AFAIK it's the main
mechanism of SCons internals)

* Rake

[snip]

 

[Nikolai Weibull]

Lionel Thiry, April 4:

I'm really curious here: what have you borrowed from SCons? Does Rant
use a directed acyclic graph for managing file dependencies?

Isn't that what all dependency-management systems use?,
nikolai

 

[Stefan Lang]

Stefan Lang a écrit :

Following your code samples, I must tell I feel it hard to see where Rant
is affiliated with Ant.

An Rantfile is Ruby code. A buildfile for Ant is XML.
Besides that, one could call Ant as project oriented. I try to achieve
a similar goal with Rant.

I'm really curious here: what have you borrowed from SCons? Does Rant use a
directed acyclic graph for managing file dependencies? (AFAIK it's the main
mechanism of SCons internals)

If I understand the definition of a DAG correctly, yes.
Rant delays dependency resolving until the point where it's actually
needed:
task :t => %w(d1 d2) do
end

task :d1 do
...
task :d2 do
end
end
When invoking task "t", Rant will first invoke dependency "d1"
which will create task "d2", then the newly created task "d2"
will be invoked and afterwards the actions for "t" will be performed.
Don't know if something like that works with SCons.

With Rant it is possible to achieve the same goals as with a "Construction
Environment" in SCons (at least AFAIK SCons), but this is currently not
documented (mainly because it's currently not very convinient to do so
and it will change, expect docs in future releases).

Note that Ant and SCons are very heavyweight compared to Rant. And Rant
is in an early stage of development. I'm using other build tools as
reference for e.g. names of commandline switches or to decide detailed
semantics.

Stefan

 

[Lionel Thiry]

Nikolai Weibull a écrit :

Lionel Thiry, April 4:




Isn't that what all dependency-management systems use?,
nikolai

Uh, well... no.

For exemple, AFAIK Rake doesn't manage file dependcies, and task dependencies
are not managed with a DAG.

 

[Lionel Thiry]

Stefan Lang a écrit :

An Rantfile is Ruby code. A buildfile for Ant is XML.
Besides that, one could call Ant as project oriented. I try to achieve
a similar goal with Rant.

There is already another project called Rant on rubyforge, and that one claims
to be a real mimick of Ant in ruby. So, I suppose telling "Rant is for Ant what
Rake is for Make" fits better for that other project.

If I understand the definition of a DAG correctly, yes.
Rant delays dependency resolving until the point where it's actually
needed:
task :t => %w(d1 d2) do
end

task :d1 do
...
task :d2 do
end
end
When invoking task "t", Rant will first invoke dependency "d1"
which will create task "d2", then the newly created task "d2"
will be invoked and afterwards the actions for "t" will be performed.
Don't know if something like that works with SCons.

With Rant it is possible to achieve the same goals as with a "Construction
Environment" in SCons (at least AFAIK SCons), but this is currently not
documented (mainly because it's currently not very convinient to do so
and it will change, expect docs in future releases).

Note that Ant and SCons are very heavyweight compared to Rant. And Rant
is in an early stage of development. I'm using other build tools as
reference for e.g. names of commandline switches or to decide detailed
semantics.

I can't tell I master those topics, but I don't think it is exactly what I was
talking about. One of the feature of SCons is to be able to automatically
generate tasks based on file dependencies. In some way, it would be as if task
d2 didn't needed to be created, SCons would have done it for you. But it would
do it the same way you stated: only when needed.

Note: SCons doesn't even stop on "automagically generate the appropriate task
and only when needed", it even tries its best to find the dependencies itself.

Second Note: I think jam works the same way.

 

[Jim Weirich]

Nikolai Weibull a écrit :

Uh, well... no.

For exemple, AFAIK Rake doesn't manage file dependcies,

If by managing file dependencies you mean automatically detect and maintain
the file dependencies, you are correct. But it is easy to get other tools to
work with rake to do that.

and task dependencies are not managed with a DAG.

Actually they are. Ok, there are no checks to enforce the acyclic nature of
the dependency graph, but the arcs of the graph are certainly directed.

 

[Stefan Lang]

Stefan Lang a écrit :

There is already another project called Rant on rubyforge, and that one
claims to be a real mimick of Ant in ruby. So, I suppose telling "Rant is
for Ant what Rake is for Make" fits better for that other project.

I encountered this project when I registered Rant on RubyForge.
Looks like it's dead. No release, no docu and about 15 kB of Ruby code.

 

[Lionel Thiry]

Jim Weirich a écrit :

If by managing file dependencies you mean automatically detect and maintain
the file dependencies, you are correct. But it is easy to get other tools to
work with rake to do that.




Actually they are. Ok, there are no checks to enforce the acyclic nature of
the dependency graph, but the arcs of the graph are certainly directed.

In Rake, the existence of the graph is implicit, hidden in the Task instances
themselves, there isn't any explicit global DAG object.

Just pointing a fact, no offense.

 

[Sam Roberts]

Quoting (e-mail address removed), on Wed, Apr 06, 2005 at 08:44:41AM +0900:

Jim Weirich a écrit :

I'm a little surprised, I though rake was supposed to be make, but with
the rules written in ruby, and maintaining file dependecies is all make
does well.

What does it mean to not maintain dependencies? What doesn't it do? If
I say (with gmake notation):

a: b.o

%.o:%.c

%.c: %.lex

Will rake not figure out how to make a out of b.lex, or are you guys
talking about something else?

Cheers,
Sam

 

[Jim Weirich]

I'm a little surprised, I though rake was supposed to be make, but with
the rules written in ruby, and maintaining file dependecies is all make
does well.

I'm not sure what the original poster meant, and tried to clarify it in my
response. Perhaps I was unclear myself.

What does it mean to not maintain dependencies? What doesn't it do? If
I say (with gmake notation):

a: b.o

%.o:%.c

%.c: %.lex

Given the explicit declaration that a depends upon b.o and the rules to
build .o from .c and .c from .lex, Rake (like make and its brethren) will
figure out how to make a from b.lex.

What Rake will /not/ do is examine your source code base and figure out that
this .o file depends on these .c files and all the header files that need to
be included in the dependency. I don't believe that make does that either,
(although I recall something about gmake in conjunction with files generated
by gcc doing something like that).

What I usually do, is run a simple dependency detection program that outputs
either rake code directly, or something that can easily be read and converted
into Rake tasks and dependencies.

 

[Jim Weirich]

In Rake, the existence of the graph is implicit, hidden in the Task
instances themselves, there isn't any explicit global DAG object.

Just pointing a fact, no offense.

None taken. You are correct. There is no one object that represents a
DAG[1]. But a DAG is merely a graph with a set of nodes and directed arcs
between the node (and no cycles too). The Task objects form the nodes of the
DAG and the directed arcs are implemented by named lookup in the task map.

You seem to imply there would be advantages to a more explicit DAG
implementation. I would be interested in hearing what you think those
advantages might be.

--
-- Jim Weirich (e-mail address removed) http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

[1] And since graphs are polylithic structures, you generally wouldn't
implement a DAG with a single object ... but I don't think that was your
point.

 

[Martin DeMello]

What I usually do, is run a simple dependency detection program that outputs
either rake code directly, or something that can easily be read and converted
into Rake tasks and dependencies.

Would it make sense to integrate the dependency detector into rake?

martin

 

[Jim Weirich]

Would it make sense to integrate the dependency detector into rake?

I would be open to that.

 

[Sam Roberts]

Quoting (e-mail address removed), on Wed, Apr 06, 2005 at 01:29:33PM +0900:

What Rake will /not/ do is examine your source code base and figure out that
this .o file depends on these .c files and all the header files that need to
be included in the dependency.

That makes sense.

I don't believe that make does that either, (although I recall
something about gmake in conjunction with files generated by gcc doing
something like that).

Yes, there are lots of dependency generators around. gcc will do it,
makedepends (distributed with X) does it well. Integrating with make is
easy:

DEPS := $(wildcard *.c)

.depends: $(DEPS)
makedepend -f- -- $(CFLAGS) -- $^ > $@

# If you include another makefile that doesn't exist, rake tries to find
# a rule to make it, and if a rule says that .depends depends on a file,
# make will remake .depends, then include it anew.
-include .depends

What I usually do, is run a simple dependency detection program that outputs
either rake code directly, or something that can easily be read and converted
into Rake tasks and dependencies.

And since ruby isn't compiled, doesn't seem like there is a lot of need
for dependency generation.

Cheers,
Sam

 

[Lionel Thiry]

Jim Weirich a écrit :

In Rake, the existence of the graph is implicit, hidden in the Task
instances themselves, there isn't any explicit global DAG object.

Just pointing a fact, no offense.

None taken. You are correct. There is no one object that represents a
DAG[1]. But a DAG is merely a graph with a set of nodes and directed arcs
between the node (and no cycles too). The Task objects form the nodes of the
DAG and the directed arcs are implemented by named lookup in the task map.

You seem to imply there would be advantages to a more explicit DAG
implementation.

Not exactly. SCons main design doc claims its cornerstone is the management of
explicit file dependency DAG. As SCons is one of the source of inspiration for
Rant, I asked if it was based on the same cornerstone.

I would be interested in hearing what you think those
advantages might be.

For Rake, the advantages of a Task Dependency Graph (TDG) _might_ be:
1) better decoupling between inner mechanisms of Rake and its interface, the
Rakefile. It would allow the development of other interfaces.
2) Easier to play with several TDG at the same time, merge them, split them, and
so on. Probably not doable with Rakefile as there is usually only one such TDG.
3) Easier to add multithreaded task execution.
4) easier to develop event listening (for example: once this target is build and
passed unit tests, send me a mail)
5) easier to develop error & exception management
6) probably a lot of other features that I haven't sight of

The disadvantages are:
1) the advantages listed above are mostly suppositions
2) DAG management code may be heavy
3) task generation on the fly as the TDG is executed may be delicate to implement
4) not sure the concept of rule can be applied easily with a TDG

 

[Nikolai Weibull]

Lionel Thiry, April 7:

SCons main design doc claims its cornerstone is the management of
explicit file dependency DAG.

Where are you reading this? What it does differently from make(1) is
that it creates a complete DAG of all dependencies, i.e., it doesn't
rely on recursive invocations (like make(1) does). That's the only
difference I know of,
nikolai

 

[Jim Weirich]

Not exactly. SCons main design doc claims its cornerstone is the management
of explicit file dependency DAG. As SCons is one of the source of
inspiration for Rant, I asked if it was based on the same cornerstone.

I scanned the Scons web site and googled for DAG. The only references to DAG
that I found were referencing the one makefile/universal DAG approach
recommended in the "Recursive Make Considered Harmful" article. I too prefer
the universal DAG approach and Rake certainly supports that way of doing
things.

If I missed something, fill me in.

For Rake, the advantages of a Task Dependency Graph (TDG) _might_ be:
1) better decoupling between inner mechanisms of Rake and its interface,
the Rakefile. It would allow the development of other interfaces.
2) Easier to play with several TDG at the same time, merge them, split
them, and so on. Probably not doable with Rakefile as there is usually only
one such TDG.
3) Easier to add multithreaded task execution.
4) easier to develop event listening (for example: once this target is
build and passed unit tests, send me a mail)
5) easier to develop error & exception management
6) probably a lot of other features that I haven't sight of

(2) I might grant, but even so I'm considering how to do something very
similar to (2) in order to support task suites. As for the others, I'm not
convinced it makes a big difference one way or another.

The disadvantages are:
1) the advantages listed above are mostly suppositions
2) DAG management code may be heavy
3) task generation on the fly as the TDG is executed may be delicate to
implement
4) not sure the concept of rule can be applied easily with a TDG

Hmmm ... (3) leads me to suspect you are really talking about marshalling or
serializing the DAG into external storage and reloading it. Is that what you
are getting at? Or am I still missing the point.

As always, thanks for the feedback.