Me again...

-----Original Message-----
From: MikkelFJ [mailto:mikkelj-anti-spam / post1.dknet.dk]
Sent: Wednesday, December 19, 2001 11:08 PM
To: ruby-talk ML; undisclosed-recipients: ;
Subject: [ruby-talk:29002] Re: Ruby 'make' replacement (Re: stderr from
external process?)



"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.
-----------------------

Yes.
We don't have to reinvent the wheel for that.
Usually, the compiler/development framework has support for dependency
generation:
- C/C++   -> VC++ has /FD, Gcc has -MM, aCC has +m, etc.
- Java    -> Jikes has +M (don't know about regular javac)
- O'Caml  -> ocamldep

Those are the few I know about. I'm sure there are other tools for other
contexts.

-----------------------
2) Ant rebuilds everything - or at least leaves the job to each individual
task.
-----------------------

I think this can be solved by relying on 1), plus a good dependency logic
(see next posts).

-----------------------
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.
-----------------------

Ok, can't comment on Jam, except that I didn't "get it" quickly enough
to believe I could really get something useful done quickly :)

-----------------------
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.
-----------------------

Cross-platform compatibility is a requirement for me.
I need to be able to have something like a "CompilerFactory" that provides
me with the correct "Compiler" object, which knows how to handle the source
and target objects.

For instance, a library being asked to be built has to access a compiler
object,
which in turn will ask for the "conceptual" options and arguments that are
attached
to the library. This compiler object will then know how to translate
those informations (e.g target.debug_level => 2) to compiler specific
settings
( GccCompiler.debug_flag(target) => "-g" ; VCppCompiler.debug_flag(target)
=> "/Zi")



-----------------------
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.
-----------------------

I'm sure one can write Ruby "build" scripts that are more readable than
my current GNU-Makefiles :)

-----------------------
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.
-----------------------

I'm currently downloading...

-----------------------
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

-----------------------

Mikkel, thanks for all those interestings comments.
I'm very open to suggestions, as you will see, but on the other hand
I need to have something working soon, so I will came up with a
"proof-of-concept" design that maybe others will enhance later.

-- Christian