From: Mike Gold Date: 2008-09-25T02:26:48+09:00 Subject: Re: Rake dependencies unknown prior to running tasks Joe Wę—¦lfel wrote: > Cleaner, maybe. But inefficient in my case. That would mean a lot > of unnecessary rebuilding. Unfortunately, efficiency matters in > this case. It can take days or weeks even with parallel builds. And > it needs to be done often. > > It seems like the wrong way to do it, but the only efficient solution > I've come up with so far is to have Rake call itself with a different > task. So basically I have dependency graph 1, which is known at the > outset and dependency graph 2 which is only known after running tasks > in dependency graph 1, and dependency graph 2 is itself dependent on > dependancy graph 1. > > It seems like a common problem. I've run into a number of build > systems that needed to be restarted several times to get around > similar issues. But if there's a better solution already out there > I'd like to use it. I don't see why it would be inefficient or require unnecessary rebuilding. If you follow the strategy I mentioned, making your changes to the graph before the first invoke, and avoiding tasks creating tasks (which is forbidden anyway with the new parallel -j support in Drake), then you've removed the dependency between graph 1 and graph 2 you describe. By removing that dependency, it becomes *more* efficient because more tasks can be parallelized, whereas before graph 1 and graph 2 had to be executed sequentially (this may not be significant in your case, but is very much so in other cases). Any build system in which the only entry point is a task -- that is, you must make a graph in order to make a graph -- would have to be run-run to compensate its lack of dynamic support. Makefiles, for example. That is why Rake is different -- you have the whole ruby language to define your tasks, and then you say "go". This two-step approach is the solution you seek. -- Posted via http://www.ruby-forum.com/.