From: Christian Boos Date: 2001-12-20T21:56:19+09:00 Subject: [ruby-talk:29105] Re: Ruby 'make' replacement (Re: stderr from external process?) 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" 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