On Oct 22, 2012, at 4:04 PM, Hongli Lai <[email protected]> wrote: > Conservative is one thing, but drake was written 2 years ago. There has been > no response every time someone asks why drake was not merged.
My main problem with drake is that it adds a second task execution engine that is subtly different the mainline rake engine. The difference isn't critical and most projects won't even notice the difference, but having two similar but different engines offends my sensibilities. If drake were to be merge, I would want to either (a) discard the current engine and use drake's engine exclusively, or (b) make the parallelization mechanism work more closely with the current rake engine. I know drake uses a dry-run pass to compute the dependency tree, but I'm not sure if the dry run pass uses the regular rake engine (which might impact option (a)) or if it does its own thing. In any case, a drake merge won't happen in the 0.9.x series as I would like to work out the current bug list and hit some simple features. The Thread pool looked like an easy win and is really needed for the multitask stuff anyways. Michael has also proposed a -m option that implicitly turns tasks into multitasks, and I'm considering that instead of a drake integration. However, if the -m flag is deemed inadequate, I will probably hold off on the thread pool as well and reconsider a drake move a bit farther down the line. Thoughts are welcome. (Postscript: I also have some concerns about turning on parallel execution in arbitrary Rakefiles. I suspect it will work fine in projects that most shell out to compilers and linkers, but Rakefiles that run most Ruby code will probably be broken in ways that are hard to detect and reproduce. If anyone has any ideas on addressing that issue, I would love to hear them.) -- -- Jim Weirich -- [email protected] _______________________________________________ Rake-devel mailing list [email protected] http://rubyforge.org/mailman/listinfo/rake-devel
