[ruby-talk:29272] Joint Builder Project (Re: Ruby 'make' replacement (Re: stderrfrom external process?))

"Luc Heinrich" <[e-mail]> wrote in message
news:[e-mail]...
> On 21/12/2001 00:30, "MikkelFJ" <[e-mail]> wrote:
>
> > And so I did.
>
> I did too, and wow, I was pretty happy because my crude little stuff has a
> lot in common with SCons: it detects changes using cached MD5 signatures,
> use scanners to find dependencies, and so on...

Interesting!

I've got a few comments at the bottom of this mail

More generally:
There seems to be several attempts to create a Ruby build system.

I think we could do something great if we join forces.

So the following is a proposal:

The feedback so far seems to suggest: New build tool in Ruby is only
justified if it brings something new to the scene.
The two great contributions to the project would be Ruby extension support
and distributed builds.
Distributed builds can both be to use resources better, but also to get the
same source build on two mirror servers without having to copy the result of
the build.

I'm pretty sure that there are some complex design issues that needs to be
resolved before an elegant light solution could be created, but also that
there are already many good ideas and partial solutions around.

If there is interested in such a joint project, I suggest we start looking
at what we already have in Ruby, and how other build systems work. Then we
put up a framework that various people can start implemting parts of.

My contribution would primarily be organization, design and analysis.

The joint build project would become part of the Ruby IDE RIDE, but should
be standalone as well.

The resulting system would be light, elegant, yet be useful for software
backup, distributed task management, download on demand, directory
replication and many other issues. And of course for compiling source code.

Let me know if there is an interest in this, and we could perhaps move to
internal mail to organize things.

emails go my address [e-mail]  where you remove the
"-anti-spam" part.
People would then be included in a bug standard list of recipients where we
can organize things a bit and possible set up a Wiki page.

I think it is possible to relatively quickly get something quite powerful in
Ruby.
But I do not underestimate the task either.
Therefore I would expect domain experts of various Ruby parts to
participate, if it should be successful.

I have a list of names I can think of - listed below. This is an expection
of those people to participate nor is it to rule out other participants. But
it does give an overview of who knows what mostly based on the recent make
thread.

I reckon the domain knowledge should make it possible to make a contribution
with a limited effort, if there is an overall sound design.

-

Luc Heinrich and Christian Boos for the main build framework - given that
they are already happily hacking along.

Phil and Jason Horman for distributed job scheduling. How can their packages
integrate and how can it integrate in a build system.

Curt Hibbs/Rich Kilmer on the sideline for RIde integration.

Johan Holmberg for design, given knownledge of Cons.

Robert Feldt if the there should be a scripting frontend due to compiler
experience.

Sean Russel if there should be a hook for Ant integration - due to combined
REXML knowledge and ANT knowledge.

Any JAM expert would be most welcome.

Plenty of other people would have an oppotunity to develop much needed build
objects once the core is complete. Amongst these can be dynamic download
support from RAA the next generation.

-

The primary object for now is to get a good understaning of other build
systems such as JAM, SCONS, ANT, and recently suggested Bras (which I
haven't looked at) http://wsd.iitb.fhg.de/~kir/brashome/
Please not that JAM should be located at www.boost.org, where they have
extended JAM significantly.

The project would - at least for me - not go live until start of the next
year. Meanwhile there should be an opportunity to get aquinted with current
build systems. I'll be pretty much off-keyboard in that period.


Here are some problems to think of:

One of the design problems that concers me is the communication between
scanners and builders. target specification based on both dependecy scanning
and directory scanning : Build those objects that object "MyFile" depends on
using the "MyScanner" dependecy scanner, but exclude any objects that are in
the File pattern specified by "MyFilePattern". The file pattern would ensure
the only files within a given subdirectory gets build, a not arbitrary
library dependencies that a dependecy scanner might suggest.

Handling (to the extend possible) scan-once then build at most once JAM
style, but maintain flexibility of pluggable scanners and builders. That is,
some kind of interface to deal with this issue.

How can distributed job specifications become a natural part of the design.

Instead of just suggesting solutions to the above, think of them as
examples - I don't even know if these are the real problems.
Identify the problems and propose solutions by looking at what other tools
identifies as problems, and what they do to solve them.

-

A few comments to Luc Heinrichs builder script:
There is not enough for me to judge on the architecture. It has some
similarities to SCons in its object model and multiple environment model, as
well as the digital signature concept.
It also has the same weakness as SCons:
Scripting inside scripting is often not as userfriendly as a dedicated
domain specific script (i.e. build script).
Whether the added benefits (and problems) of a dedicated script is worthwile
is a design issue that needs to be considered.

There seem to be a misconception that when you script something in a host
langugae, you get the full power of the host language. However, the
expressiveness of the system has more to do with its architecture. An
example is Rockit: It's input is not described in a Ruby script, but rather
in a dedicated language syntax script.
Hence you could have a dedicated easy to use scripting language that could
embed Ruby or refer to external Ruby files, but which itself would have a
cleaner syntax dedicated to the build problem.

However, an object model such as SCons or the builder.rb is the precondition
for a dedicated build script, therefore it is a perfectly valid and
desireable approach.


MikkelFJ