On Sep 10, 9:13 ¨Βν¬ ΚιΧειςιγΌκ®®®ΐχειςιγθθουσε®οςηχςοτεΊ > Thomas Sawyer wrote: > > On Sep 10, 7:59 am, Jim Weirich <j... / weirichhouse.org> wrote: > >> in that order. However, that doesn't provide any guarantees that they > >> (its just more likely that the drake will make this kind of bug > >> manifest). > > > Ah, so by design you consider it a bug. You could have fixed that from > > day one by randomizing the order of the prerequisites. Now you have a > > situation where many Rakefiles depend on that bug. So, why not turn > > lemons into lemonade, and make this bug a feature? > > I'm not sure what you are advocating here: > > (1) Guarantee that rake will invoke the prerequisites in the defined > order? ... we already do that (for standard non-tasking rake). > > (2) Guarantee that rake will execute the prerequisites in the defined > order? .. Can't do that, prerequisite constraints elsewhere may > constrain the execution to be a different order. > > (3) Declare that I don't mind if you make unwarranted assumptions about > execution order? ... Well, as long as you don't file bug reports, I'm ok > with that. > > More clarification on Rake terminology: > > To execute a task means to execute any code blocks attached to the task > (i.e. the do/end part of a task). > > To invoke a task means to make sure all the prerequisites for the task > have been invoked and then execute the task if it has not yet been > executed. ¨Β τασλ ιξφογατιοξ χιμμ ξοεψεγυττθτασλ ιζ ιτ θααμςεαδ> been executed. > > In standard rake, the order of dependencies only specifies the > invocation order, not the execution order. ¨Βου ξεφεχεςε αβμε το > directly control execution order of tasks via the order of the > dependency list. And yet we can use the execution order in practice: F = [] G = [] task :f do F.replace([1,2,3]) end task :g do if F.empty? G.replace([4,5,6]) else G.replace(F) end end desc "use f and g not defined by f" task :g1 => [:g, :f] do p G, F end desc "use f and g defined by f" task :g2 => [:f, :g] do p G, F end I understand that the formal design did not intend for this. But implementation allows it. Is it worth potentially breaking Rakefiles to prevent this sort of thing (like drake -j2 or more does)? I'm not so sure. While one might consider this Rakefile "bad design" because it doesn't fit the original formal notion, it nonetheless does what one would expect it to do. I think I'd rather have that, than the potential for ambiguous behavior. T.