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 -~----------~----~----~----~------~----~------~--~---