mac: In component builds, put all chrome code in a nonbundle dylib. 25% faster incremental builds.

mac: In component builds, put all chrome code in a nonbundle dylib. 25% faster incremental builds.

In a components build, make chrome_dll a very thin shim that includes
all the bundle resources but no code, give it type shared_library/bundle
(currently it's type none) and make it -reexport_library chrome_main_dll.
Also move all postbuilds to this target. (To make this maintainable, all the
bundle stuff was moved to a separate gypi file previously that's now just
included in a different place.)

Keep all sources in chrome_main_dll, but turn it from a bundle into a
regular shared library. 

With this, gyp's ld optimization becomes active for chrome_mail_dll,
which means all the bundle stuff (most notably postbuilds) don't need to
run after touching a file below chrome/. 

Touching file in c/b/ui and rebuilding:
7.7s -> 5.8s (download_show_all_cell.mm, SSD), or
8.3s -> 6.4s (omnibox_popup_view_mac.mm, SSD) 
19.7s -> 16.7s (hover_button.mm, HDD)

From 

0. ninja figures out deps (0.7s) 
1. compile changed file (~1s) 
2. libtool libchrome_browser_ui.a (~2s) 
3. touch obj/chrome/chrome_main_dll.actions_depends.stamp 
4. ld Chromium Framework (~2s) 
5. package-framework Chromium Framework 
6. ld libplugin_carbon_interpose.dylib 
7. ld Chromium Helper 
8. change_mach_o_flags_from_xcode.sh for Chromium Helper 
9. touch obj/chrome/chrome.actions_depends.stamp 
10. ln libplugin_carbon_interpose.dylib to Contents/Versions/... 
11. same for Chromium Framework 
12. touch obj/chrome/chrome.actions_rules_copies.stamp 
13. ld Chromium main executable 
14. Main executable postbuilds (tweak_info_plist.py, make_more_helpers, ...) 


to 

0. ninja figures out deps (0.7s) 
1. compile changed file (~1s) 
2. libtool libchrome_browser_ui.a (~2s) 
3. ld libchrome_main_dll.dylib (~2s)

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=168314

[Mark Mentovai, 2012-11-16 02:22:59]

What does this mean? What’s “gyp’s ld optimization?”

With this, gyp's ld optimization becomes active for chrome_mail_dll,
> which means all the bundle stuff (most notably postbuilds) don't need to
> run after touching a file below chrome/.
>

[Nico, 2012-11-16 02:31:08]

On Thu, Nov 15, 2012 at 6:22 PM, Mark Mentovai <mark@chromium.org> wrote:
> What does this mean? What’s “gyp’s ld optimization?”

This: https://chromiumcodereview.appspot.com/10704054

>
>> With this, gyp's ld optimization becomes active for chrome_mail_dll,
>> which means all the bundle stuff (most notably postbuilds) don't need to
>> run after touching a file below chrome/.

[Mark Mentovai, 2012-11-16 02:35:34]

OK. I wanted to make sure, because that shouldn’t actually be interfering
with postbuilds.

Postbuilds are supposed to run all the time, even if the things in the
immediate target haven’t changed. This is because we hang tasks like
dump_syms and other things that might depend on other (possibly indirect)
dependencies off of postbuilds. We even hang the Info.plist whacker off of
postbuilds, which uses the source code revision, something that isn’t even
necessarily expressed in any of the dependencies.

This change itself is fine, but it shouldn’t result in any speedup by
avoiding postbuilds, because postbuilds can’t be avoided. If ninja is
behaving differently than Xcode here, then it’s a ninja bug that would
inhibit full adoption of ninja as an Xcode replacement.


On Thu, Nov 15, 2012 at 9:31 PM, Nico Weber <thakis@chromium.org> wrote:

> On Thu, Nov 15, 2012 at 6:22 PM, Mark Mentovai <mark@chromium.org> wrote:
> > What does this mean? What’s “gyp’s ld optimization?”
>
> This: https://chromiumcodereview.appspot.com/10704054
>
> >
> >> With this, gyp's ld optimization becomes active for chrome_mail_dll,
> >> which means all the bundle stuff (most notably postbuilds) don't need to
> >> run after touching a file below chrome/.
>

[Nico, 2012-11-16 02:42:44]

On Thu, Nov 15, 2012 at 6:35 PM, Mark Mentovai <mark@chromium.org> wrote:
> OK. I wanted to make sure, because that shouldn’t actually be interfering
> with postbuilds.
>
> Postbuilds are supposed to run all the time, even if the things in the
> immediate target haven’t changed. This is because we hang tasks like
> dump_syms and other things that might depend on other (possibly indirect)
> dependencies off of postbuilds. We even hang the Info.plist whacker off of
> postbuilds, which uses the source code revision, something that isn’t even
> necessarily expressed in any of the dependencies.
>
> This change itself is fine, but it shouldn’t result in any speedup by
> avoiding postbuilds, because postbuilds can’t be avoided. If ninja is
> behaving differently than Xcode here, then it’s a ninja bug that would
> inhibit full adoption of ninja as an Xcode replacement.

ninja (and make) only run postbuilds on targets that have changed.

>
>
> On Thu, Nov 15, 2012 at 9:31 PM, Nico Weber <thakis@chromium.org> wrote:
>>
>> On Thu, Nov 15, 2012 at 6:22 PM, Mark Mentovai <mark@chromium.org> wrote:
>> > What does this mean? What’s “gyp’s ld optimization?”
>>
>> This: https://chromiumcodereview.appspot.com/10704054
>>
>> >
>> >> With this, gyp's ld optimization becomes active for chrome_mail_dll,
>> >> which means all the bundle stuff (most notably postbuilds) don't need
>> >> to
>> >> run after touching a file below chrome/.
>
>

[Mark Mentovai, 2012-11-16 03:10:35]

ninja and make are wrong, then. They are especially wrong in light of the
ld optimization.


On Thu, Nov 15, 2012 at 9:42 PM, Nico Weber <thakis@chromium.org> wrote:

> On Thu, Nov 15, 2012 at 6:35 PM, Mark Mentovai <mark@chromium.org> wrote:
> > OK. I wanted to make sure, because that shouldn’t actually be interfering
> > with postbuilds.
> >
> > Postbuilds are supposed to run all the time, even if the things in the
> > immediate target haven’t changed. This is because we hang tasks like
> > dump_syms and other things that might depend on other (possibly indirect)
> > dependencies off of postbuilds. We even hang the Info.plist whacker off
> of
> > postbuilds, which uses the source code revision, something that isn’t
> even
> > necessarily expressed in any of the dependencies.
> >
> > This change itself is fine, but it shouldn’t result in any speedup by
> > avoiding postbuilds, because postbuilds can’t be avoided. If ninja is
> > behaving differently than Xcode here, then it’s a ninja bug that would
> > inhibit full adoption of ninja as an Xcode replacement.
>
> ninja (and make) only run postbuilds on targets that have changed.
>
> >
> >
> > On Thu, Nov 15, 2012 at 9:31 PM, Nico Weber <thakis@chromium.org> wrote:
> >>
> >> On Thu, Nov 15, 2012 at 6:22 PM, Mark Mentovai <mark@chromium.org>
> wrote:
> >> > What does this mean? What’s “gyp’s ld optimization?”
> >>
> >> This: https://chromiumcodereview.appspot.com/10704054
> >>
> >> >
> >> >> With this, gyp's ld optimization becomes active for chrome_mail_dll,
> >> >> which means all the bundle stuff (most notably postbuilds) don't need
> >> >> to
> >> >> run after touching a file below chrome/.
> >
> >
>

[Nico, 2012-11-16 03:20:06]

I disagree. I'm not sure if that's relevant for this cl though.
On Nov 15, 2012 7:10 PM, "Mark Mentovai" <mark@chromium.org> wrote:

> ninja and make are wrong, then. They are especially wrong in light of the
> ld optimization.
>
>
> On Thu, Nov 15, 2012 at 9:42 PM, Nico Weber <thakis@chromium.org> wrote:
>
>> On Thu, Nov 15, 2012 at 6:35 PM, Mark Mentovai <mark@chromium.org> wrote:
>> > OK. I wanted to make sure, because that shouldn’t actually be
>> interfering
>> > with postbuilds.
>> >
>> > Postbuilds are supposed to run all the time, even if the things in the
>> > immediate target haven’t changed. This is because we hang tasks like
>> > dump_syms and other things that might depend on other (possibly
>> indirect)
>> > dependencies off of postbuilds. We even hang the Info.plist whacker off
>> of
>> > postbuilds, which uses the source code revision, something that isn’t
>> even
>> > necessarily expressed in any of the dependencies.
>> >
>> > This change itself is fine, but it shouldn’t result in any speedup by
>> > avoiding postbuilds, because postbuilds can’t be avoided. If ninja is
>> > behaving differently than Xcode here, then it’s a ninja bug that would
>> > inhibit full adoption of ninja as an Xcode replacement.
>>
>> ninja (and make) only run postbuilds on targets that have changed.
>>
>> >
>> >
>> > On Thu, Nov 15, 2012 at 9:31 PM, Nico Weber <thakis@chromium.org>
>> wrote:
>> >>
>> >> On Thu, Nov 15, 2012 at 6:22 PM, Mark Mentovai <mark@chromium.org>
>> wrote:
>> >> > What does this mean? What’s “gyp’s ld optimization?”
>> >>
>> >> This: https://chromiumcodereview.appspot.com/10704054
>> >>
>> >> >
>> >> >> With this, gyp's ld optimization becomes active for chrome_mail_dll,
>> >> >> which means all the bundle stuff (most notably postbuilds) don't
>> need
>> >> >> to
>> >> >> run after touching a file below chrome/.
>> >
>> >
>>
>
>

[Mark Mentovai, 2012-11-16 03:36:39]

Well, the way you say ninja and make work, nobody’s Info.plist would ever
be rebuilt once put in place, because main executables never change, right?
Now developers don’t get Info.plist updates in their local builds unless
they clobber? Developers building in a Breakpad-enabled configuration (note
that with bpoop, all configurations will be Breakpad-enabled) don’t get
updated symbols dumped unless they clobber? That’s really bad.

Let’s think of a way to be constructive about this. How can we get tasks
that need to run regardless of whether their associated target relinked
(like dump_syms) to run all the time, while tasks that are strictly related
to their own target linking (like strip) are restricted to looking just at
their own target?


On Thu, Nov 15, 2012 at 10:20 PM, Nico Weber <thakis@chromium.org> wrote:

> I disagree. I'm not sure if that's relevant for this cl though.
> On Nov 15, 2012 7:10 PM, "Mark Mentovai" <mark@chromium.org> wrote:
>
>> ninja and make are wrong, then. They are especially wrong in light of the
>> ld optimization.
>>
>>
>> On Thu, Nov 15, 2012 at 9:42 PM, Nico Weber <thakis@chromium.org> wrote:
>>
>>> On Thu, Nov 15, 2012 at 6:35 PM, Mark Mentovai <mark@chromium.org>
>>> wrote:
>>> > OK. I wanted to make sure, because that shouldn’t actually be
>>> interfering
>>> > with postbuilds.
>>> >
>>> > Postbuilds are supposed to run all the time, even if the things in the
>>> > immediate target haven’t changed. This is because we hang tasks like
>>> > dump_syms and other things that might depend on other (possibly
>>> indirect)
>>> > dependencies off of postbuilds. We even hang the Info.plist whacker
>>> off of
>>> > postbuilds, which uses the source code revision, something that isn’t
>>> even
>>> > necessarily expressed in any of the dependencies.
>>> >
>>> > This change itself is fine, but it shouldn’t result in any speedup by
>>> > avoiding postbuilds, because postbuilds can’t be avoided. If ninja is
>>> > behaving differently than Xcode here, then it’s a ninja bug that would
>>> > inhibit full adoption of ninja as an Xcode replacement.
>>>
>>> ninja (and make) only run postbuilds on targets that have changed.
>>>
>>> >
>>> >
>>> > On Thu, Nov 15, 2012 at 9:31 PM, Nico Weber <thakis@chromium.org>
>>> wrote:
>>> >>
>>> >> On Thu, Nov 15, 2012 at 6:22 PM, Mark Mentovai <mark@chromium.org>
>>> wrote:
>>> >> > What does this mean? What’s “gyp’s ld optimization?”
>>> >>
>>> >> This: https://chromiumcodereview.appspot.com/10704054
>>> >>
>>> >> >
>>> >> >> With this, gyp's ld optimization becomes active for
>>> chrome_mail_dll,
>>> >> >> which means all the bundle stuff (most notably postbuilds) don't
>>> need
>>> >> >> to
>>> >> >> run after touching a file below chrome/.
>>> >
>>> >
>>>
>>
>>

[Nico, 2012-11-16 17:40:14]

On 2012/11/16 03:36:39, Mark Mentovai wrote:
> Well, the way you say ninja and make work, nobody’s Info.plist would ever
> be rebuilt once put in place, because main executables never change, right?

The ld trick isn't done for bundles. Info.plists are bundle resources, and
bundles depend on their bundle resources, so when any resource (e.g. an
Info.plist) changes, the bundle gets rebuilt.

> Now developers don’t get Info.plist updates in their local builds unless
> they clobber? Developers building in a Breakpad-enabled configuration (note
> that with bpoop, all configurations will be Breakpad-enabled) don’t get
> updated symbols dumped unless they clobber? That’s really bad.

No, postbuilds run on targets that have changed.

> Let’s think of a way to be constructive about this. How can we get tasks
> that need to run regardless of whether their associated target relinked
> (like dump_syms) to run all the time, while tasks that are strictly related
> to their own target linking (like strip) are restricted to looking just at
> their own target?

I filed http://crbug.com/161488 for the postbuilds discussion. It feels
unrelated to this CL.

> 
> 
> On Thu, Nov 15, 2012 at 10:20 PM, Nico Weber <mailto:thakis@chromium.org>
wrote:
> 
> > I disagree. I'm not sure if that's relevant for this cl though.
> > On Nov 15, 2012 7:10 PM, "Mark Mentovai" <mailto:mark@chromium.org> wrote:
> >
> >> ninja and make are wrong, then. They are especially wrong in light of the
> >> ld optimization.
> >>
> >>
> >> On Thu, Nov 15, 2012 at 9:42 PM, Nico Weber <mailto:thakis@chromium.org>
wrote:
> >>
> >>> On Thu, Nov 15, 2012 at 6:35 PM, Mark Mentovai <mailto:mark@chromium.org>
> >>> wrote:
> >>> > OK. I wanted to make sure, because that shouldn’t actually be
> >>> interfering
> >>> > with postbuilds.
> >>> >
> >>> > Postbuilds are supposed to run all the time, even if the things in the
> >>> > immediate target haven’t changed. This is because we hang tasks like
> >>> > dump_syms and other things that might depend on other (possibly
> >>> indirect)
> >>> > dependencies off of postbuilds. We even hang the Info.plist whacker
> >>> off of
> >>> > postbuilds, which uses the source code revision, something that isn’t
> >>> even
> >>> > necessarily expressed in any of the dependencies.
> >>> >
> >>> > This change itself is fine, but it shouldn’t result in any speedup by
> >>> > avoiding postbuilds, because postbuilds can’t be avoided. If ninja is
> >>> > behaving differently than Xcode here, then it’s a ninja bug that would
> >>> > inhibit full adoption of ninja as an Xcode replacement.
> >>>
> >>> ninja (and make) only run postbuilds on targets that have changed.
> >>>
> >>> >
> >>> >
> >>> > On Thu, Nov 15, 2012 at 9:31 PM, Nico Weber <mailto:thakis@chromium.org>
> >>> wrote:
> >>> >>
> >>> >> On Thu, Nov 15, 2012 at 6:22 PM, Mark Mentovai
<mailto:mark@chromium.org>
> >>> wrote:
> >>> >> > What does this mean? What’s “gyp’s ld optimization?”
> >>> >>
> >>> >> This: https://chromiumcodereview.appspot.com/10704054
> >>> >>
> >>> >> >
> >>> >> >> With this, gyp's ld optimization becomes active for
> >>> chrome_mail_dll,
> >>> >> >> which means all the bundle stuff (most notably postbuilds) don't
> >>> need
> >>> >> >> to
> >>> >> >> run after touching a file below chrome/.
> >>> >
> >>> >
> >>>
> >>
> >>

[Mark Mentovai, 2012-11-16 17:47:50]

The reason that it’s related to this CL:

Since postbuilds behave as you say in ninja and make, but were running on
all builds all along up until this point because of a side effect of how
the .gyp files specified the build, then we had a build system problem that
nobody ever noticed because of the side effect.

This CL proposes to remove or alter that side effect. In that case, we’ll
have a build system problem that won’t be accounted for by anything else.

I’m sure you can understand that I don’t want to break things for people,
but I’m afraid that given the state of how some of these build systems
work, accepting this reorganization now without accounting for the
differences between these build systems will cause things to break. I’m not
against this change at all, and in fact I agree that we should find a way
to identify and express which postbuilds ought to be tied to the link step
and which need to run regardless of the linker and cut everyone’s
incremental build times. More importantly, I want to ensure that the build
is correct and remains correct. “25% faster” sounds great, but you’re
really just talking about a flat 1.9 second improvement, and I don’t think
we need to rush through this just for 1.9 seconds per build.


On Fri, Nov 16, 2012 at 12:40 PM, <thakis@chromium.org> wrote:

> On 2012/11/16 03:36:39, Mark Mentovai wrote:
>
>> Well, the way you say ninja and make work, nobody’s Info.plist would ever
>> be rebuilt once put in place, because main executables never change,
>> right?
>>
>
> The ld trick isn't done for bundles. Info.plists are bundle resources, and
> bundles depend on their bundle resources, so when any resource (e.g. an
> Info.plist) changes, the bundle gets rebuilt.
>
>
>  Now developers don’t get Info.plist updates in their local builds unless
>> they clobber? Developers building in a Breakpad-enabled configuration
>> (note
>> that with bpoop, all configurations will be Breakpad-enabled) don’t get
>> updated symbols dumped unless they clobber? That’s really bad.
>>
>
> No, postbuilds run on targets that have changed.
>
>
>  Let’s think of a way to be constructive about this. How can we get tasks
>> that need to run regardless of whether their associated target relinked
>> (like dump_syms) to run all the time, while tasks that are strictly
>> related
>> to their own target linking (like strip) are restricted to looking just at
>> their own target?
>>
>
> I filed http://crbug.com/161488 for the postbuilds discussion. It feels
> unrelated to this CL.
>
>
>
>  On Thu, Nov 15, 2012 at 10:20 PM, Nico Weber <mailto:thakis@chromium.org>
>>
> wrote:
>
>  > I disagree. I'm not sure if that's relevant for this cl though.
>> > On Nov 15, 2012 7:10 PM, "Mark Mentovai" <mailto:mark@chromium.org>
>> wrote:
>> >
>> >> ninja and make are wrong, then. They are especially wrong in light of
>> the
>> >> ld optimization.
>> >>
>> >>
>> >> On Thu, Nov 15, 2012 at 9:42 PM, Nico Weber <mailto:
>> thakis@chromium.org>
>>
> wrote:
>
>> >>
>> >>> On Thu, Nov 15, 2012 at 6:35 PM, Mark Mentovai <mailto:
>> mark@chromium.org>
>>
>> >>> wrote:
>> >>> > OK. I wanted to make sure, because that shouldn’t actually be
>> >>> interfering
>> >>> > with postbuilds.
>> >>> >
>> >>> > Postbuilds are supposed to run all the time, even if the things in
>> the
>> >>> > immediate target haven’t changed. This is because we hang tasks like
>> >>> > dump_syms and other things that might depend on other (possibly
>> >>> indirect)
>> >>> > dependencies off of postbuilds. We even hang the Info.plist whacker
>> >>> off of
>> >>> > postbuilds, which uses the source code revision, something that
>> isn’t
>> >>> even
>> >>> > necessarily expressed in any of the dependencies.
>> >>> >
>> >>> > This change itself is fine, but it shouldn’t result in any speedup
>> by
>> >>> > avoiding postbuilds, because postbuilds can’t be avoided. If ninja
>> is
>> >>> > behaving differently than Xcode here, then it’s a ninja bug that
>> would
>> >>> > inhibit full adoption of ninja as an Xcode replacement.
>> >>>
>> >>> ninja (and make) only run postbuilds on targets that have changed.
>> >>>
>> >>> >
>> >>> >
>> >>> > On Thu, Nov 15, 2012 at 9:31 PM, Nico Weber <mailto:
>> thakis@chromium.org>
>>
>> >>> wrote:
>> >>> >>
>> >>> >> On Thu, Nov 15, 2012 at 6:22 PM, Mark Mentovai
>>
> <mailto:mark@chromium.org>
>
>  >>> wrote:
>> >>> >> > What does this mean? What’s “gyp’s ld optimization?”
>> >>> >>
>> >>> >> This:
https://chromiumcodereview.**appspot.com/10704054<https://chromiumcodereview....
>> >>> >>
>> >>> >> >
>> >>> >> >> With this, gyp's ld optimization becomes active for
>> >>> chrome_mail_dll,
>> >>> >> >> which means all the bundle stuff (most notably postbuilds) don't
>> >>> need
>> >>> >> >> to
>> >>> >> >> run after touching a file below chrome/.
>> >>> >
>> >>> >
>> >>>
>> >>
>> >>
>>
>
>
>
https://codereview.chromium.**org/11420019/<https://codereview.chromium.org/1...
>

[Nico, 2012-11-16 17:59:01]

On Fri, Nov 16, 2012 at 9:47 AM, Mark Mentovai <mark@chromium.org> wrote:
> The reason that it’s related to this CL:
>
> Since postbuilds behave as you say in ninja and make, but were running on
> all builds all along up until this point

No, because many things (base, net, content, webkit) are already components.

> because of a side effect of how the
> .gyp files specified the build, then we had a build system problem that
> nobody ever noticed because of the side effect.
>
> This CL proposes to remove or alter that side effect. In that case, we’ll
> have a build system problem that won’t be accounted for by anything else.
>
> I’m sure you can understand that I don’t want to break things for people,
> but I’m afraid that given the state of how some of these build systems work,
> accepting this reorganization now without accounting for the differences
> between these build systems will cause things to break. I’m not against this
> change at all, and in fact I agree that we should find a way to identify and
> express which postbuilds ought to be tied to the link step and which need to
> run regardless of the linker and cut everyone’s incremental build times.
> More importantly, I want to ensure that the build is correct and remains
> correct. “25% faster” sounds great, but you’re really just talking about a
> flat 1.9 second improvement, and I don’t think we need to rush through this
> just for 1.9 seconds per build.
>
>
> On Fri, Nov 16, 2012 at 12:40 PM, <thakis@chromium.org> wrote:
>>
>> On 2012/11/16 03:36:39, Mark Mentovai wrote:
>>>
>>> Well, the way you say ninja and make work, nobody’s Info.plist would ever
>>> be rebuilt once put in place, because main executables never change,
>>> right?
>>
>>
>> The ld trick isn't done for bundles. Info.plists are bundle resources, and
>> bundles depend on their bundle resources, so when any resource (e.g. an
>> Info.plist) changes, the bundle gets rebuilt.
>>
>>
>>> Now developers don’t get Info.plist updates in their local builds unless
>>> they clobber? Developers building in a Breakpad-enabled configuration
>>> (note
>>> that with bpoop, all configurations will be Breakpad-enabled) don’t get
>>> updated symbols dumped unless they clobber? That’s really bad.
>>
>>
>> No, postbuilds run on targets that have changed.
>>
>>
>>> Let’s think of a way to be constructive about this. How can we get tasks
>>> that need to run regardless of whether their associated target relinked
>>> (like dump_syms) to run all the time, while tasks that are strictly
>>> related
>>> to their own target linking (like strip) are restricted to looking just
>>> at
>>> their own target?
>>
>>
>> I filed http://crbug.com/161488 for the postbuilds discussion. It feels
>> unrelated to this CL.
>>
>>
>>
>>> On Thu, Nov 15, 2012 at 10:20 PM, Nico Weber <mailto:thakis@chromium.org>
>>
>> wrote:
>>
>>> > I disagree. I'm not sure if that's relevant for this cl though.
>>> > On Nov 15, 2012 7:10 PM, "Mark Mentovai" <mailto:mark@chromium.org>
>>> > wrote:
>>> >
>>> >> ninja and make are wrong, then. They are especially wrong in light of
>>> >> the
>>> >> ld optimization.
>>> >>
>>> >>
>>> >> On Thu, Nov 15, 2012 at 9:42 PM, Nico Weber
>>> >> <mailto:thakis@chromium.org>
>>
>> wrote:
>>>
>>> >>
>>> >>> On Thu, Nov 15, 2012 at 6:35 PM, Mark Mentovai
>>> >>> <mailto:mark@chromium.org>
>>>
>>> >>> wrote:
>>> >>> > OK. I wanted to make sure, because that shouldn’t actually be
>>> >>> interfering
>>> >>> > with postbuilds.
>>> >>> >
>>> >>> > Postbuilds are supposed to run all the time, even if the things in
>>> >>> > the
>>> >>> > immediate target haven’t changed. This is because we hang tasks
>>> >>> > like
>>> >>> > dump_syms and other things that might depend on other (possibly
>>> >>> indirect)
>>> >>> > dependencies off of postbuilds. We even hang the Info.plist whacker
>>> >>> off of
>>> >>> > postbuilds, which uses the source code revision, something that
>>> >>> > isn’t
>>> >>> even
>>> >>> > necessarily expressed in any of the dependencies.
>>> >>> >
>>> >>> > This change itself is fine, but it shouldn’t result in any speedup
>>> >>> > by
>>> >>> > avoiding postbuilds, because postbuilds can’t be avoided. If ninja
>>> >>> > is
>>> >>> > behaving differently than Xcode here, then it’s a ninja bug that
>>> >>> > would
>>> >>> > inhibit full adoption of ninja as an Xcode replacement.
>>> >>>
>>> >>> ninja (and make) only run postbuilds on targets that have changed.
>>> >>>
>>> >>> >
>>> >>> >
>>> >>> > On Thu, Nov 15, 2012 at 9:31 PM, Nico Weber
>>> >>> > <mailto:thakis@chromium.org>
>>>
>>> >>> wrote:
>>> >>> >>
>>> >>> >> On Thu, Nov 15, 2012 at 6:22 PM, Mark Mentovai
>>
>> <mailto:mark@chromium.org>
>>
>>> >>> wrote:
>>> >>> >> > What does this mean? What’s “gyp’s ld optimization?”
>>> >>> >>
>>> >>> >> This: https://chromiumcodereview.appspot.com/10704054
>>> >>> >>
>>> >>> >> >
>>> >>> >> >> With this, gyp's ld optimization becomes active for
>>> >>> chrome_mail_dll,
>>> >>> >> >> which means all the bundle stuff (most notably postbuilds)
>>> >>> >> >> don't
>>> >>> need
>>> >>> >> >> to
>>> >>> >> >> run after touching a file below chrome/.
>>> >>> >
>>> >>> >
>>> >>>
>>> >>
>>> >>
>>
>>
>>
>> https://codereview.chromium.org/11420019/
>
>

[Mark Mentovai, 2012-11-16 19:32:12]

The Info.plist tweaker is sensitive to changes that may not be expressed in
built-up binaries at all.

[Mark Mentovai, 2012-11-16 19:32:41]

That comment was meant for the bug, not this review.

[Mark Mentovai, 2012-11-16 22:35:31]

LGTM as not blocked by 161488 following discussion on that bug.