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 <dglaz...@google.com>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<jor...@chromium.org> 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 <bradnel...@google.com>
> > 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 <jor...@chromium.org>
> >> wrote:
> >>>
> >>> On Mon, Aug 10, 2009 at 10:45 PM, Aaron Boodman <a...@chromium.org>
> 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: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
