Never mind, that line is already complete!
GENERATE_BINDINGS_SCRIPTS = \
bindings/scripts/CodeGenerator.pm \
bindings/scripts/IDLParser.pm \
bindings/scripts/IDLStructure.pm \
bindings/scripts/generate-bindings.pl \
On Tue, Aug 11, 2009 at 7:51 AM, Eric Seidel <[email protected]> wrote:
> IDL file tracking is part of why WebKit uses "DerivedSources.make" (which I
> assume Chromium does to? Or at least we will eventually need to if we're
> going to have an upstream WebKit build...)
> JS%.h : %.idl $(GENERATE_BINDINGS_SCRIPTS)
> bindings/scripts/CodeGeneratorJS.pm
> $(GENERATE_BINDINGS) --defines "$(FEATURE_DEFINES)
> LANGUAGE_JAVASCRIPT" --generator JS $<
>
> That line actually should depend on all of the .pm files in
> bindings/scripts, but generally CodeGeneratorJS.pm has been enough.
>
> -eric
>
> On Tue, Aug 11, 2009 at 7:25 AM, Dimitri Glazkov <[email protected]>wrote:
>
>>
>> The culprit here was the change to the CodeGeneratorV8.pm. It looks
>> like we should somehow trigger clobber of of rule_binding.py when that
>> happens.
>>
>> :DG<
>>
>> On Mon, Aug 10, 2009 at 11:24 PM, Jeremy Orlow<[email protected]>
>> wrote:
>> > They were both WebKit deps rolls. The latter one was caused by an .idl
>> file
>> > that changed.
>> > The former, I don't know off the top of my head. Here's the chromium
>> > review: http://codereview.chromium.org/165278 Here are the files that
>> > changed:
>> http://trac.webkit.org/changeset?new=47...@trunk&old=46...@trunk
>> > Here's the error visual studio gave:
>> >
>> > DerivedSourcesAllInOne.cpp
>> >
>> C:\b\slave\win\build\src\chrome\Debug\obj\webcore\bindings/V8Document.cpp(1003)
>> > : error C2039: 'v8ElementEventHandlerAccessorGetter' : is not a member
>> of
>> > 'WebCore::V8Custom'
>> >
>> >
>> C:\b\slave\win\build\src\third_party\WebKit\WebCore\bindings\v8\custom\V8CustomBinding.h(94)
>> > : see declaration of 'WebCore::V8Custom'
>> >
>> >
>> >
>> >
>> > On Mon, Aug 10, 2009 at 11:17 PM, Bradley Nelson <[email protected]
>> >
>> > wrote:
>> >>
>> >> We currently have a hack of sorts in mind (well an issue filed on gyp)
>> >> that would cover a larger class of settings changes (the worst handled
>> by
>> >> vstudio directly). The idea is to have gyp generate a text file full of
>> >> settings garp which would be an additional dependency of each project.
>> >> There are of course other dependency flaws (sgk is working on a long
>> >> running validation build that would look for missing links in the
>> chain)
>> >> that are just due to mistakes in the gyp files.
>> >> I would be curious which kind of dependency issue these latest ones
>> were
>> >> (can someone point me at the CLs?, been on nacl/o3d buildbot stuff of
>> late).
>> >> -BradN
>> >> On Mon, Aug 10, 2009 at 11:00 PM, Jeremy Orlow <[email protected]>
>> >> wrote:
>> >>>
>> >>> On Mon, Aug 10, 2009 at 10:45 PM, Aaron Boodman <[email protected]>
>> wrote:
>> >>>>
>> >>>> Such a system does not help when people sync your change. We should
>> >>>> invest the effort we would expend building this system fixing the
>> >>>> dependency issues.
>> >>>
>> >>> gclient could be made to obey it as well. But I agree, it's a hack.
>> >>>
>> >>>>
>> >>>> Barring that, we have a hack that we do where for resource files we
>> >>>> make a whitespace change to the corresponding .gyp. We could automate
>> >>>> this by having a presubmit check that enforces this.
>> >>>
>> >>> Better than nothing.
>> >>> We also have the hack for grd files that deletes all the associated .h
>> >>> files. Something like that might work here as well.
>> >>> How hard would it be to make the system actually understand the
>> >>> dependencies? Is visual studio really just too dumb to understand?
>> >>>
>> >>
>> >
>> >
>> > >
>> >
>>
>> >>
>>
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: [email protected]
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
