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

I didn't say what was being built couldn't be determined  
programmatically.  I said it couldn't be determined until certain  
portions were already built.  To build those things initial things I  
need a build tool, such as Rake.  If the suggestion is that I  
shouldn't actually execute any Rake tasks until after I've determined  
all possible tasks then the catch 22 your talking about actually  
occurs.  The only practical solution I've come up with so far is to  
have Rake build the initial targets and then call itself again to  
determine the rest of the dependency graph and build the remaining  
targets.   If there were a way to augment the initial dependency  
graph dynamically then this wouldn't be necessary.   I just don't  
happen to know of one.


On 24 sept. 08, at 14:37, Mike Gold wrote:

> Joe Wölfel wrote:
>>> I don't see why it would be inefficient or require unnecessary
>>> rebuilding.
>>
>> The reason is because I have to build things before I know (or can
>> even determine programmatically) what other things need to be built.
>
> If you can't determine programmaticaly what is built, then how does a
> program build it?
>
> Even C/C++ dependencies, where you have no clue what g++ -MM is  
> going to
> spit out, can be handled with 'import' and the makefile loader.
>
> If you are executing some other program which generates stuff, perhaps
> you can add a flag where the program outputs what it *would* generate.
> Capture that and 'import' it.
>
> And if you can't add that flag, or if you otherwise don't know what is
> being generated, then your hands are tied anyway.  You can't know  
> what's
> going to happen, so you can't do anything about it.  The two graphs  
> are
> worlds apart, and never the twain shall meet.  In this case I wonder
> what solution you could have expected.
> -- 
> Posted via http://www.ruby-forum.com/.
>