On Tue, Aug 4, 2009 at 7:31 PM, Alex Boisvert <[email protected]> wrote:

> I've managed to narrow down the issue to the
> Buildr::Extension::ClassMethods.callbacks method which returns an invalid
> Callback instance.  I came up with a quick fix but I'm not sure why this is
> happening or if it's the right solution.
>
> boisv...@sixtine:~/svn/buildr-ext$ svn-diff
> Index: lib/buildr/core/project.rb
> ===================================================================
> --- lib/buildr/core/project.rb    (revision 801046)
> +++ lib/buildr/core/project.rb    (working copy)
> @@ -755,7 +755,11 @@
>     private
>
>       def callbacks
> -        const_get('Callbacks') rescue const_set('Callbacks', Class.new)
> +        if constants.include?("Callbacks")
> +          const_get('Callbacks')
> +        elsif
> +          const_set('Callbacks', Class.new)
> +        end
>       end
>
>     end
>
> Without this fix, the "first_time" method of the extension is never
> called.   Assaf, can you take a look?   We should probably open a bug since
> apparently this breaks all 3rd-party extensions.


const_get throws an exception if the constant is not defined, so these two
should be equivalent under Ruby 1.8.  Not under 1.9, under 1.9 constants()
returns an array of symbols which does not include the string, and so the
constant will get set twice with two different classes.

If this works under 1.9, it's only because it's hiding another bug: probably
double application of first_time on the same extension.

Everything in Buildr is an extension added on to project, if first_time
decided to stop working, so would compiling, testing, packaging, etc.

Assaf


>
>
> alex
>
> On Mon, Aug 3, 2009 at 3:08 PM, Daniel Spiewak <[email protected]>
> wrote:
>
> > I can reproduce the problem (and your solution).  It still doesn't make
> any
> > sense to me though.  Actually, it's probably indicative of some deeper
> > problem with the way we're using Rake.  Assaf, I'm getting well out of my
> > depth here, could you look at this?
> >
> > Daniel
> >
> > On Mon, Aug 3, 2009 at 4:59 PM, Martin Grotzke <
> > [email protected]
> > > wrote:
> >
> > > I did this:
> > >
> > > module LinesOfCode
> > >  include Extension
> > >
> > >  desc "WeirdWeirdWeird"
> > >  Project.local_task('loc')
> > >  first_time do
> > >    # Define task not specific to any project.
> > >    #Project.local_task('loc')
> > >  end
> > >
> > >  ...
> > >
> > > end
> > >
> > > And now buildr -T shows the loc task as "WeirdWeirdWeird"...
> > >
> > > Just for interest: what's the behaviour of the loc extension when you
> > > require it in one of your buildfiles? Can't you reproduce the behaviour
> > > I'm describing?
> > >
> > > Cheers,
> > > Martin
> > >
> > >
> > >
> > > On Mon, 2009-08-03 at 16:35 -0500, Daniel Spiewak wrote:
> > > > That doesn't make any sense to me.  I've done a number of extensions
> > now
> > > > using local_task, none of them have had any problems.  Just looking
> at
> > > your
> > > > sources, everything should work.  Just for kicks, try moving the
> > > local_task
> > > > bit *out* of the first_time block, see what happens.
> > > >
> > > > Daniel
> > > >
> > > > On Mon, Aug 3, 2009 at 3:03 PM, Martin Grotzke <
> > > [email protected]
> > > > > wrote:
> > > >
> > > > > Ok, thanks for the hint! However, using `task` doesn't change
> > anything
> > > > > for me. buildr -T still prints the available loc tasks as
> myproj:loc
> > > and
> > > > > myproj:mysubproj:loc. Invoking `buildr loc` results in
> > > > >  Don't know how to build task 'loc'
> > > > >
> > > > > Removing the first_time stuff also doesn't change anything, I can
> > > remove
> > > > > it without (obvious) consequences.
> > > > >
> > > > > But to be honest: this is not an issue for me, I just wanted to
> > mention
> > > > > this so that the documentation containing this (extending.textile)
> > can
> > > > > be improved :)
> > > > >
> > > > > Cheers,
> > > > > Martin
> > > > >
> > > > >
> > > > > On Mon, 2009-08-03 at 12:03 -0500, Daniel Spiewak wrote:
> > > > > > You should use `task` rather than `define_task`.  I think that's
> > > probably
> > > > > > the root of all your problems.  My changes can be seen here:
> > > > > > http://github.com/djspiewak/buildr-addons/tree/master
> > > > > >
> > > > > > Daniel
> > > > > >
> > > > > > On Mon, Aug 3, 2009 at 11:43 AM, Martin Grotzke <
> > > > > > [email protected]> wrote:
> > > > > >
> > > > > > > Here's the loc extension (loc.rb):
> > > > > > > http://github.com/magro/buildr-addons/tree/master
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Martin
> > > > > > >
> > > > > > >
> > > > > > > On Mon, 2009-08-03 at 11:29 -0500, Daniel Spiewak wrote:
> > > > > > > > That really doesn't make any sense.  Could we see the full
> > > sources?
> > > > > > > >
> > > > > > > > Daniel
> > > > > > > >
> > > > > > > > On Mon, Aug 3, 2009 at 4:58 AM, Martin Grotzke <
> > > > > > > [email protected]
> > > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > And I noticed that with the example one has to invoke
> > > > > > > > >   buildr myproj:loc
> > > > > > > > > for the project or
> > > > > > > > >   buildr myproj:mysubproj:loc
> > > > > > > > > for a subproject.
> > > > > > > > >
> > > > > > > > > The
> > > > > > > > >  first_time do
> > > > > > > > >    Project.local_task('loc')
> > > > > > > > >  end
> > > > > > > > > seems to have no effect.
> > > > > > > > >
> > > > > > > > > Is this intended?
> > > > > > > > >
> > > > > > > > > Cheers,
> > > > > > > > > Martin
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Mon, 2009-08-03 at 11:47 +0200, Martin Grotzke wrote:
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > I just want to create a sloccount extension and for this
> > > started
> > > > > with
> > > > > > > > > > the loc example.
> > > > > > > > > >
> > > > > > > > > > I had to do minor changes, which I applied to the
> > > > > extending.textile:
> > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> http://github.com/magro/buildr/commit/b880acaca4892a4000143d089b59873247808bc0
> > > > > > > > > >
> > > > > > > > > > Without these changes:
> > > > > > > > > > - the task is not shown with buildr -T
> > > > > > > > > > - the task fails if the source directories also contain
> > > > > > > subdirectories
> > > > > > > > > > (which is normally the case)
> > > > > > > > > >
> > > > > > > > > > Cheers,
> > > > > > > > > > Martin
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
>

Reply via email to