On Fri, Jul 24, 2009 at 11:10 AM, Tony Chang <[email protected]> wrote:
> I haven't seen this error in VS for probably a year. It's true that > changing a resource (e.g., a png file) would not pick up the change > since we don't specify dependencies on the actual data files, but > changes to grd files should trigger the right things to rebuild. > > When we see the error on the buildbots, what's normally happening is > that a new resource is added which causes IDs after the new resource > to shift. The header is updated with the new values and new .rc files > are generated. The .rc files properly get rebuilt into the locale dll > since the .rc files changed. However, some of the .cc files don't > recompile so they are referencing the old IDs and get the wrong > resource (e.g., we would get the wrong title for a tab). > > Is there a recent build log where this failed? I think we'll be able > to determine more from that. the build never actually fails, but the test fails, and it's exactly what you said, it expects STRINGX, but gets STRINGY (which happened to have the same ID that STRINGX had before). I still think this is expected. Modifying a rc file should not force every files which depends on it to rebuild. Since when you use the VS UI, it will never change the order, so the rebuild will be useless. (And if you add or delete a string, you'll have the cc files containing them modified anyway, so it will rebuild correctly that part). I guess someone should try it ;) Nicolas > > On Fri, Jul 24, 2009 at 11:00 AM, Nicolas Sylvain<[email protected]> > wrote: > > Tony, just to make sure, are you certain that this is a IB only issue? > > I used to be convinced that it was happening with visual studio too. > > If this is a IB only problem, we should create a repro case and send it > to > > them, they > > are usually really responsive. > > [For some reasons, I thought it was because it was generating the rc > files > > and the ID in them were not static. I.e. you add a string in the middle, > and > > it's shifting the string IDs of all the strings after the addition. > Visual > > Studio does not support that. You can't change string ids in a RC file > > without having the clobber the source. The normal use case is always to > take > > the next available ID (which is why the rc file always keep track of the > > next available ID at the bottom).] > > Nicolas > > > > On Thu, Jul 23, 2009 at 5:54 PM, Tony Chang <[email protected]> wrote: > >> > >> Look at how the current gyp hook works. It looks for changes to .gyp > >> files and only runs if a .gyp (and maybe gypi?) file has changed. > >> > >> You can find what header it generates by opening the grd file and > >> parsing the XML (the XML lists the output files). You'll need to > >> build the base directory (e.g., Debug/obj/global_intermediate/ and the > >> Release version), I would just check for the Windows versions since we > >> don't seem to have this problem with the mac or linux buildbots. > >> > >> > >> > >> On Thu, Jul 23, 2009 at 5:36 PM, Paweł Hajdan > >> Jr.<[email protected]> wrote: > >> > I think that this workaround may be worth it. I'm not familiar with > the > >> > IncrediBuild, but I can help making the hook (and we can run it only > on > >> > Windows). > >> > How do I make a hook know which grd files changed? And also know which > >> > headers it generates? Alternatively, maybe this Windows-only hook > would > >> > just > >> > delete all generated headers (with a hardcoded list)? Generation seems > >> > to be > >> > cheap, and such hook seems trivial to write. > >> > So, yes, this hook is kludgey. But we are aware of its limitations, > and > >> > it > >> > would eliminate one kind of build mysteries. What do you think? > >> > > >> > On Thu, Jul 23, 2009 at 17:30, Tony Chang <[email protected]> wrote: > >> >> > >> >> Here's a crappy work around: > >> >> Add a gclient hook that checks for grd file changes. When a grd file > >> >> changes, force delete the header it would generate. I'm pretty sure > >> >> this would prevent bad builds from IncrediBuild. > >> >> > >> >> Alternately, maybe we can make a reduced test case and file a bug > >> >> against IncrediBuild. > >> >> > >> >> On Thu, Jul 23, 2009 at 4:44 PM, Paweł Hajdan > >> >> Jr.<[email protected]> wrote: > >> >> > Is it possible to force it to rebuild some files, or... I don't > know, > >> >> > do > >> >> > you > >> >> > see some real way to fix this problem? > >> >> > > >> >> > On Thu, Jul 23, 2009 at 16:41, Tony Chang <[email protected]> > wrote: > >> >> >> > >> >> >> To elaborate on Peter's comment. IncrediBuild (which the > buildbots > >> >> >> use) get confused by changes to our grd files. Our grd files > >> >> >> generate > >> >> >> headers, which should then cause lots of cc files to get rebuilt. > >> >> >> Visual Studio seems to always get this right, but IncrediBuild > gets > >> >> >> this wrong and cc files don't get rebuilt. I imagine IncrediBuild > >> >> >> is > >> >> >> checking the timestamp of the file before the headers are > >> >> >> re-generated > >> >> >> and doesn't realize it needs to rebuild. > >> >> >> > >> >> >> On Thu, Jul 23, 2009 at 4:38 PM, Peter Kasting< > [email protected]> > >> >> >> wrote: > >> >> >> > On Thu, Jul 23, 2009 at 4:31 PM, Paweł Hajdan Jr. > >> >> >> > <[email protected]> > >> >> >> > wrote: > >> >> >> >> > >> >> >> >> Some of the flaky failures are caused by resource bundle > issues. > >> >> >> >> If > >> >> >> >> you > >> >> >> >> are familiar with the build process, or the resource bundle, > >> >> >> >> please > >> >> >> >> take a > >> >> >> >> look. > >> >> >> > > >> >> >> > It looks like something needed a manual clobber and didn't get > it. > >> >> >> > PK > >> >> >> > >> >> > > >> >> >> > > >> >> > > >> >> > > >> > > >> > > >> > >> > >> > > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
