This problem could also be solved by ignoring DerivedSources.make, and instead just add the "source" files to the vcproj. Then write a custom .rules file for each file type that runs the appropriate batch command to create the generated file. Then, dependency tracking would work just as it does for .cpp files. Our DerivedSources.make is already so tremendously out of sync with the one upstream that there doesn't seem to be much point in using it.
-Darin On Sun, Jan 4, 2009 at 3:12 PM, Brett Wilson <[email protected]> wrote: > > On Sun, Jan 4, 2009 at 11:28 AM, Mike Belshe <[email protected]> wrote: > > It's been this way for a while; the good news is that it should only > > happen on initial build; subsequent builds don't regenerate the > > bindings. > > The problem is that I (and it seems like many other people) have > learned that you have to do a full build basically every time you > sync, because the dependencies aren't computed properly. Ironically > the biggest problem of incorrect dependencies is the generated files! > That's why I was suggesting the solution that will help both of these > problems. > > > If 3 minutes is really too much for a full build, we could > > do your #2; hopefully the dependency checker would be smart enough not > > to rebuild them if they were checked in. We'd have to find where to > > check them in as well, because currently they are built into the > > output directory (for both Release and Debug; perhaps we could just > > generate one set, as I don't think they differ between release/debug > > builds) > > I think we would need a new DEPS entry for them. Ojan's WebKit sync > script could probably do the management of this automatically. > > Brett > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
