"Stefan Schmiedl" <s / xss.de> wrote in message
news:20011219184639.E17292 / workhorse...
> Christian Boos (2001-12-20 01:57):

> take a look at the Ant projekt, originating from apache.
> it's an xml-based make replacement.
> you might want to consider being ant.xml compatible.

I did look at Ant.
I think it definitely is worthwile supporting Ant. It is really quite easy
to implement Ant in Ruby, assuming RexML does a decent job.
Most of the work in Ant is to large number of tasks. This will of course
take some time, but it should not be that difficult to support the Core Ant.
Unfortunately the API doc is missing.

But there are also problems with Ant.
1) It does not handle dependency generation.
I want good customized dependecy generation - Jam has customized
headerscanning. Ant only has a crude - this task depends on that task - it
is ok for many purposes but could be better.
I would like a tool that can generate dependencies both using header
scanning, but also using other means. It should be pluggable.
2) Ant rebuilds everything - or at least leaves the job to each individual
task.
3) Ant is not very customizable unless you want to hook into the Ant API.
This is quite elegant and not too hard - once you understand. Jam is easier
in this respect because you can easily write powerful build rules. But Jam
is very difficult to understand. There are so many implicit counterintuitive
things going on - but it is powerful.
4) Ant is not very configurable with respect to handling multiple tools for
identical files. Jam easily sets up different rules for different C++
compiles on different operating systems. Ant is clearly written for a
controlled enviroment i.e. Java. That is not so say that you cant do such
things with a bit of work.

I see no reason why Ant shouldn't be supported with similar exension classes
in Ruby.
But I'd like a close look on what kind of solution Jam provides. The power
of jam made more accessible would be a good thing.

Also, both Jam and Ant claims that they do not want to be yet another
scripting language. Yet more and more script like features for dependency
rules and scoped variables creep in. I would like a fully scriptable build
system that direktly uses the Ruby scripting.

A problem with using Ruby directly as opposed to a build file like Ant xml
files or Jam files are, that you these Task.Addfiles(x.cpp, y.cpp) etc. as
have also been suggested here. I'd like a cleaner syntax, but still have
Ruby scripting.
One solution is to create a build syntax that embeds Ruby. Another approach
is to look at UnitTesting frameworks - they essentially do perform a kind of
task control. The one recently posted in this newsgroup is a way to go:
Instead of test_assert { 2 < 4 }, you could have something like target_x {
|x| x.depend(:target_y) } or something... Again, a dedicated script langauge
is better - but you could have both. The Torrent Workflow also suggests an
xml descriptor file as a todo.

The Torrent Workflow is a recently RAA posted workflow scheduler that is
quite useful for build framework.
Unfortunately it is GPL'ed, which makes it of limited use. On the positive
side, it is not difficult to copy the concept.

With respect to the dependecy generation - I do not understand Jam well
enough. But it has a pre-build step for generating dependencies. Perhaps
some kind of double make process can be engaged: First a make to create
dependencies. Then a make to build the files. Or perhaps they can be
intergrated in the same step. I'm particulary thinking of custom dependency
parsers, and tools like ocamldepend the first parses sources then generates
a dependency file, which then needs to be parsed into the build description.

In conclusion I like the Ant concept, but I would rather have a tool like
Jam. Just a version that does not require two weeks of headbanging before
you can do anything useful with it.
I also think a scripting language that can be expressed in XML might be
nice, but it should have a non-xml version for user input.
Oh well, and it should also build files that are not Ruby files, but I guess
that is kind of self evident :-)
Most of the work is in the design. A pure Ant solution with a limited task
subset should be not be too difficult.



MikkelFJ