On Sep 10, 10:58 ¨Âí¬ ¢®¼ñõéøïôéãóùãïðè®®®Àçíáéì®ãïí÷òïôåº
> On Sep 10, 2:06 ¨Âí¬ Ôòáî¼ôòáîóæ®®®Àçíáéì®ãïí÷òïôåº
>
> > 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.
>
> Underspecified dependencies + parallel execution == ambiguous behavior

They are only unspecified according to an interpretation of how things
ought to be. In the current implementation Rake is executing in a
predictable order. One can use it, and people have. Maybe not formally
ideal but the functionality is there. But that's not whast really
concerns me. The issue I was looking at was:

  drake -j2 + Rakefile = ambiguous behavior

So I was suggesting that it would perhaps be better to accept rake's
current implementation behavior; this ambiguity would then not arise;
and instead provide another notation to indicate parallel execution.
My particular idea might not be the best one, I was just looking for a
possible solution that could be useful in itself and address this
issue. Another possibility is just placing a statement at the
beginning of a Rakefile that could be used to indicate that the
rakefile is in fact "j-able".

I thought it prudent to address this b/c, personally, I'd like to see -
j end up in Rake itself. But perhaps it is better to just move forward
and expect people to fix all there old Rakefiles (and lets just hope
nothing really ugly happens when they haven't).

> > There's no such thing as luck in computer programming.
>
> Yes, there is.

And his name is _why? ;) Well, i suppose if we want to take chances,
then there is.

T.