Jim Weirich a ˝─rit :
> On Wednesday 06 April 2005 05:44 pm, Lionel Thiry wrote:
> 
>>>You seem to imply there would be advantages to a more explicit DAG
>>>implementation.
>>
>>Not exactly. SCons main design doc claims its cornerstone is the management
>>of explicit file dependency DAG. As SCons is one of the source of
>>inspiration for Rant, I asked if it was based on the same cornerstone.
> 
> 
> I scanned the Scons web site and googled for DAG.  The only references to DAG 
> that I found were referencing the one makefile/universal DAG approach 
> recommended in the "Recursive Make Considered Harmful" article.  I too prefer 
> the universal DAG approach and Rake certainly supports that way of doing 
> things.
> 
> If I missed something, fill me in.

http://www.scons.org/doc/PDF/scons-design.pdf

> 
> 
>>>I would be interested in hearing what you think those
>>>advantages might be.

I have forgotten one, the way tasks are executed. You can execute the TDG in 
such a way that you don't have to check repeatedly each task to know if it has 
already been executed. You just begin at the right starting nodes and follows 
the arrows.

Well, that's what I thought until I tried to code that myself. What a nightmare! :)

 >>For Rake, the advantages of a Task Dependency Graph (TDG) _might_ be:
 >>1) better decoupling between inner mechanisms of Rake and its interface,
 >>the Rakefile. It would allow the development of other interfaces.
 >>2) Easier to play with several TDG at the same time, merge them, split
 >>them, and so on. Probably not doable with Rakefile as there is usually only
 >>one such TDG.
 >>3) Easier to add multithreaded task execution.
 >>4) easier to develop event listening (for example: once this target is
 >>build and passed unit tests, send me a mail)
 >>5) easier to develop error & exception management
 >>6) probably a lot of other features that I haven't sight of
 >
 >
 > (2) I might grant, but even so I'm considering how to do something very
 > similar to (2) in order to support task suites.
 > As for the others, I'm not
 > convinced it makes a big difference one way or another.

Do you mean that every thing in the list above can already be done with rake? Or 
will be added to rake? Will you really add all these features?

Especially about (1), would you plan to decouple Rake interface (the Rakefiles) 
and Rake internals? Said another way, would you plan to make rake usable through 
a standard ruby script?

  require 'rake'
  # do rake stuff but more explicitly
  # no more implicit tasks or rules
  # no more implicit management of options

Not being able to do this is what disturbs me the most about rake.


 >>The disadvantages are:
 >>1) the advantages listed above are mostly suppositions
 >>2) DAG management code may be heavy
 >>3) task generation on the fly as the TDG is executed may be delicate to
 >>implement
 >>4) not sure the concept of rule can be applied easily with a TDG
 >
 >
 > Hmmm ... (3) leads me to suspect you are really talking about marshalling or
 > serializing the DAG into external storage and reloading it.  Is that what you
 > are getting at?

No.

I've already thought about that, but I don't know how to solve the problem of 
serializing ruby blocks.

 >  Or am I still missing the point.

I was thinking about tasks that create tasks.

For example, let's say task1 generate a source file. But then, you want to 
compile that source file too and you may don't know in advance how to do that 
until you know exactly what kind of source file has been generated.

A possible solution is that when task1 has generated its target, it checks the 
type of the result and then generates, on the fly, a task2 in charge of 
compiling that file.

Another solution could be to have a kind of task template ready for 
instanciation with the right parameters from another task.


 >
 > As always, thanks for the feedback.
 >

--
Lionel Thiry