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.
On Fri, Jul 24, 2009 at 11:00 AM, Nicolas Sylvain<nsylv...@chromium.org> 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 <t...@chromium.org> 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.<phajdan...@chromium.org> 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 <t...@chromium.org> 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.<phajdan...@chromium.org> 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 <t...@chromium.org> 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<pkast...@google.com>
>> >> >> wrote:
>> >> >> > On Thu, Jul 23, 2009 at 4:31 PM, Paweł Hajdan Jr.
>> >> >> > <phajdan...@chromium.org>
>> >> >> > 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: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
