From: MikkelFJ Date: 2001-12-20T07:08:07+09:00 Subject: [ruby-talk:29002] Re: Ruby 'make' replacement (Re: stderr from external process?) "Stefan Schmiedl" 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