From: "Joe Wölfel" <joe@...>
Date: 2008-09-25T01:38:08+09:00
Subject: Re: Rake dependencies unknown prior to running tasks

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.

On 24 sept. 08, at 12:02, Mike Gold wrote:

> Mike Gold wrote:
>> Joe Wölfel wrote:
>>> Say I don't know what all the dependencies are until I've already
>>> begun executing tasks?  To what extent can I add new tasks and
>>> dependencies on the fly?
>>
>> This is what 'import' is for
>
> Sorry I just realized you meant that you actually create new tasks  
> after
> the task invocations have begun.
>
> In this case, are you certain those things creating tasks should be
> tasks?  It seems like you should have normal ruby classes/methods  
> which
> determine which tasks to create, then create them.  That is what I do.
>
> I think this strategy covers all cases, even though you may need to
> restructure your code.  But in the end it's a cleaner approach, IMO.
> -- 
> Posted via http://www.ruby-forum.com/.
>