PS: here's a hack I did in make.gyp to output a rule that manually
touches the output file to work around this. Perhaps you could do
something in your Xcode generator to work around it for now.
# Deep inside the "rules" conversions code path:
if name == 'resources_grit':
# HACK: This is ugly. Grit intentionally doesn't touch the
# timestamp of its output file when the file doesn't change,
# which is fine in hash-based dependency systems like scons
# and forge, but not kosher in the make world. After some
# discussion, hacking around it here seems like the least
# amount of pain.
fp.write('\...@touch --no-create $...@\n')
On Mon, Apr 27, 2009 at 3:12 PM, Evan Martin <[email protected]> wrote:
> The build system has a generation dependency path like this:
>
> 1) final output depends on
> 2) grit header and cc, which depends on
> 3) grit input .grd file, which depends on
> 4) theme resources
>
> This means whenever you tweak theme resources, you cause a recompile,
> even when the .cc and .h in (2) don't change. So Glen requested Tony
> change grit to not touch the outputs if their contents don't change,
> and that's what's causing the problem.
>
> This works fine for scons (because it uses file content hashes to
> compute whether dependencies need rebuilding), but breaks systems
> (including make and Xcode) that rely on file timestamps. Why?
> Because you end up with the timestamp of 3 being newer than the
> timestamp of 2, so the dependency checker thinks you always need to
> re-run grit to convert 3=>2.
>
> The symptom you get is that grit runs every time you build.
>
> I think the correct fix is to make grit just modify the output files,
> like every other program does. Sorry, Glen.
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: [email protected]
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
