On Thu, Oct 30, 2008 at 6:42 AM, Jim Weirich <[EMAIL PROTECTED]> wrote:
> > On Oct 28, 2008, at 9:17 PM, James M. Lawrence wrote: > > When I saw commit 995b742d "fixed namespace task list bug" I was >> reminded of the problem I had in Drake where Task#prerequisites gave >> namespace-unqualified task names >> (http://rubyforge.org/pipermail/rake-devel/2008-September/000574.html). >> >> namespace :a do >> task :x >> task :y => :x >> end >> >> task :default do >> p Rake::Task["a:y"].prerequisites #=> ["x"] >> # should be ["a:x"] ? >> end >> >> Does this work as designed? I had initially conjectured that you >> wanted a task manager to have context-dependent behavior (where the >> "x" prereq can mean something different depending on the current >> namespace), but it doesn't look like Rake is designed this way. >> > > Yes, this works as designed. The prerequisites are deliberately stored as > name references that are looked up in the tasks scope. It is the lookup > process that applies the namespace resolution, not the definition process. > > Although your suggestions makes a lot of sense. I should reevaluate that > decision. > > The other issue was that File#needed? does not look past its immediate >> prereqs. >> > > Hmmm, interesting. I will confess that I'm not entirely sure why it works > that way, and yet it will correctly rebuild out of date files. I'll take > another look at this code when I'm not so tired and maybe enlightenment will > occur. (FYI, the needed? method was originally within the first 1 hour of > the creation of Rake) > Isn't it that needed? is called after invoke_prerequisites? Since child has bee invoked, it touched "child" and so grandchild will see that one of its prerequisites is newer. I think this is good for two reasons: 1. performance wise, 2. it means "child" can have some logic in its block to determine if updating itself is needed, only if it updated itself, will "parent" be invoked. Ittay > > > -- > -- Jim Weirich > -- [EMAIL PROTECTED] > > > _______________________________________________ > Rake-devel mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/rake-devel >
_______________________________________________ Rake-devel mailing list [email protected] http://rubyforge.org/mailman/listinfo/rake-devel
