Bennett, Patrick wrote:
Is there no interest in the suggestion made below?
Drawbacks:
This doesn't allow for a task's action to add prerequisites to sibling
tasks during the invocation chain (unless an API is provided to allow
changing the invocation list during invocation)
For me at least, this is a *huge* drawback. I add new tasks and modify
existing tasks during task execution all the time.
Having the execution order determined all at once up-front would be a
big problem.
The flow is like this:
* you build the task dependency tree as today
* rake starts to invoke the top tasks:
* instead of letting each task invoke its prerequisites, rake asks it
to return its prerequisites
* so here you can override the 'prerequisites' method and add and
modify tasks
* now rake orders the prerequisites according to their dependencies
and executes them
This is just making the flow iterative instead of recursive: explicitly
maintaining the stack of tasks instead of relying on ruby's call stack.
I don't think much will change. But, by avoiding recursion, there's no
risk of exhausting the call stack and there's a much better way of
parallelizing the build
Ittay
Patrick Bennett
_______________________________________________
Rake-devel mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rake-devel
--
--
Ittay Dror <[EMAIL PROTECTED]>
_______________________________________________
Rake-devel mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rake-devel
