From: MikkelFJ Date: 2001-12-21T08:30:49+09:00 Subject: [ruby-talk:29178] Re: Ruby 'make' replacement (Re: stderr from external process?) "> You may want to look at Scons (www.scons.org): And so I did. I need to look at it more though. I covers all the issues I have mentioned. At least in its statet goals. If it delivers what it claims in what I have already read, I think this is a very good system. There is one issue that concerns me slightly: Can SCons correctly ensure that a build source mentioned multiple times will only be targeted once. It does have a digital signature, but I'm not sure what happens if the same file happens to be represented in two build objects instead of one. This is a point that Jam goes to great lengths to handle. But even if SCons doesn't do this as well, it still looks great. Among the features are custom scanners for dependencies. I think I'm going to try it out to see if I can use it as a build system, although this would require me to get at least slightly aquainted with Python... I have to look more at the system to say anymore specific - so I shall be general. I previously mentioned that the greatest work in creating a better Ant system would be in the design. It appears that SCons has done this design and done it right. Hence if a build system is to be developed in Ruby, I think that it might well stay close to SCons. Scons claims it is extensible such that you could implement Make compatibility if you'd care to do it. You could probably put Ant compatibility into it as well. That would mean no loss of generality by staing with SCons. SCons has a job system that by description sounds much like Torrent. It also has or plans to have VPATH support. Personally I do not fully understand the concept, but suspect it to be a useful path translation mechanism. It is being mentioned as an important feature elsewhere. So the big question is: Why on earth should we clone SCons in Ruby, if we choose to copy the concept without bringing something unique to it. Well - personally my need for a Ruby build system seems to have been reduced. But one answer would be: because you can! Another answer is that it would be a natural fit to the planned Ruby IDE. Third, it would allow standard build scripting to be done in our favorite language. Last and perhaps most importantly, it would allow for build tasks to be written in Ruby - and you can so many cool things with a good buildsystem that is only vaguely related to actually building software. In other words, it is a good framework to have on top of the grand unified Torrent, Distrubed Tasks framework. So - assuming SCons proves worthy as a design model for a Rubuild System the next question is: Should it attempt to state compatible (not quite as ruby scripting is not python scripting), or should it just pick the ideas and go its own way - adding distributed builds with no regard to the future direction of SCons? Going for compatibility - there might be a common interchange XML format not unlike Ant, but also not quite the same because of the scanner objects and generally different model. You can't do everything in such a shared framework, but you could do a lot things that way. It would assume keywords in the XML script would be reflected in Ruby and Python objects respectively. I'm not personally sure I like to involve XML in this, but if interoperation is desireable, this may be the way to go. If distributed builds are being implemented, one could also figure a way for SCons and Rubuild to communicate via XML-RPC or similar. Btw: What about an extra dependency step that builds libraries that doesn't exists by downloading them automatically. This may be the RAA.succ idea Robert Feldt mentions - but since I don't know about RAA.succ I can't tell. Note that this has nothing to do with the build tool per se. It is just another build task like zipping files or compiling. It's just dependencies taken a step further. The above is just a bit of brainstorming, and I haven't even looked closely at SCons yet. MikkelFJ