- Remove '-parallelizeTargets' from xcodebuild invocation as it eats

- Remove '-parallelizeTargets' from xcodebuild invocation as it eats
  the error messages if a build fails when using Xcode 4.4.
Committed: https://code.google.com/p/dart/source/detail?r=14950

[Ivan Posva, 2012-11-15 09:03:00]

Both Matthias and I ran into this independently today.

-Ivan

[ahe, 2012-11-15 09:57:03]

I suspect this will greatly increase build times, so I think it needs to be an
option.

Also, could you provide me with an example where you saw this?  I'd like to
attempt to reproduce it and come out with a solution that doesn't disable
parallelizing builds.

Alternatively, we could investigate switching to ninja builds on Mac.  I hear
they are faster.

[Ivan Posva, 2012-11-15 10:12:49]

On 2012/11/15 09:57:03, ahe wrote:
> I suspect this will greatly increase build times, so I think it needs to be an
> option.
> 
> Also, could you provide me with an example where you saw this?  I'd like to
> attempt to reproduce it and come out with a solution that doesn't disable
> parallelizing builds.
> 
> Alternatively, we could investigate switching to ninja builds on Mac.  I hear
> they are faster.

You just need a compilation failure or another build step failure (e.g.
gen_snapshot failing) in your checkout and if you are unlucky enough then you
get no error message printed and all you have is BUILD FAILED.

It looks to me that if there is a build step printing while another target
fails, the error message is eaten. In the best case all you get is BUILD FAILED,
in the worst case you are sent on a wild goose chase as a totally unrelated file
is marked as failing to compile, but without any error message for that file.
Parallel programming is hard.

 As this has happened in at least three different settings today and you will
invariably chase the wrong thing for many minutes, I will gladly eat the
potential slow down. Although I did not perceive any (no measurements though).

-Ivan

[ahe, 2012-11-15 10:36:43]

On 2012/11/15 10:12:49, Ivan Posva wrote:
> On 2012/11/15 09:57:03, ahe wrote:
> > I suspect this will greatly increase build times, so I think it needs to be
an
> > option.
> > 
> > Also, could you provide me with an example where you saw this?  I'd like to
> > attempt to reproduce it and come out with a solution that doesn't disable
> > parallelizing builds.
> > 
> > Alternatively, we could investigate switching to ninja builds on Mac.  I
hear
> > they are faster.
> 
> You just need a compilation failure or another build step failure (e.g.
> gen_snapshot failing) in your checkout and if you are unlucky enough then you
> get no error message printed and all you have is BUILD FAILED.
> 
> It looks to me that if there is a build step printing while another target
> fails, the error message is eaten. In the best case all you get is BUILD
FAILED,
> in the worst case you are sent on a wild goose chase as a totally unrelated
file
> is marked as failing to compile, but without any error message for that file.
> Parallel programming is hard.
> 
>  As this has happened in at least three different settings today and you will
> invariably chase the wrong thing for many minutes, I will gladly eat the
> potential slow down. Although I did not perceive any (no measurements though).
> 
> -Ivan

I think we need to switch to ninja.  Clearly, xcodebuild is inferior for
building from command line and is causing random crashes on our build bots.  In
addition, xcodebuild attempts to run actions whose dependencies are failing. 
Generally, this makes output from xcodebuild unreadable.

[ahe, 2012-11-15 11:25:26]

LGTM.

I think we will do the following:

* Make build.py use ninja by default on Mac.

* By default, only generate ninja build files on Mac.

* Configure an FYI builder that tests that xcodebuild continues to work for
people who use Xcode for development, and for Chromium integration.