improve xcode_emulation.py

improve xcode_emulation.py

+ Improved SDK path lookup: now also supports iPhoneOS and iPhoneSimulator SDKs
+ Adds support for options CLANG_CXX_LANGUAGE_STANDARD, CLANG_CXX_LIBRARY,
  CLANG_WARN_CONSTANT_CONVERSION
+ Adds support for IPHONEOS_DEPLOYMENT_TARGET (iphoneos and iphonesimulator)

BUG=

[kal, 2013-03-10 09:00:25]

Please review my code.

[Nico, 2013-03-11 17:14:40]

Thanks for the patch! This looks really good.

Can you add a few tests? We don't have any ios tests yet, you can add test/ios
for this. Please also add tests for the -std=c++11, -stdlib=libc++ flags. A test
for Wconstant-conversion is nice to have, but not required.

The main point of the tests is to make sure that defaults match xcodebuilds
behavior. You can run the mac tests with `python gyptest.py test/mac`. Pass `-a`
instead of a directory to run all tests. You can also pass `-f generatorname` to
run only some generators (`-f ninja,xcode` for example).

https://codereview.chromium.org/12725005/diff/1/pylib/gyp/xcode_emulation.py
File pylib/gyp/xcode_emulation.py (right):

https://codereview.chromium.org/12725005/diff/1/pylib/gyp/xcode_emulation.py#...
pylib/gyp/xcode_emulation.py:224: job = subprocess.Popen(['xcodebuild',
'-version', '-sdk', sdk, infoitem],
Nice!

https://codereview.chromium.org/12725005/diff/1/pylib/gyp/xcode_emulation.py#...
pylib/gyp/xcode_emulation.py:229: print out
Isn't `err` more interesting?

[kal, 2013-03-11 20:33:23]

On 2013/03/11 17:14:40, Nico wrote:
> Thanks for the patch! This looks really good.
> 
> Can you add a few tests? We don't have any ios tests yet, you can add test/ios
> for this. Please also add tests for the -std=c++11, -stdlib=libc++ flags. A
test
> for Wconstant-conversion is nice to have, but not required.
> 
> The main point of the tests is to make sure that defaults match xcodebuilds
> behavior. You can run the mac tests with `python gyptest.py test/mac`. Pass
`-a`
> instead of a directory to run all tests. You can also pass `-f generatorname`
to
> run only some generators (`-f ninja,xcode` for example).
> 
> https://codereview.chromium.org/12725005/diff/1/pylib/gyp/xcode_emulation.py
> File pylib/gyp/xcode_emulation.py (right):
> 
>
https://codereview.chromium.org/12725005/diff/1/pylib/gyp/xcode_emulation.py#...
> pylib/gyp/xcode_emulation.py:224: job = subprocess.Popen(['xcodebuild',
> '-version', '-sdk', sdk, infoitem],
> Nice!
> 
>
https://codereview.chromium.org/12725005/diff/1/pylib/gyp/xcode_emulation.py#...
> pylib/gyp/xcode_emulation.py:229: print out
> Isn't `err` more interesting?

Err, yes 'err' should be more interesting :) I'll change that.

How does this work, if I want to make a change or add tests? I'm using git. How
to I upload a change/update patch to this same issue?

[Nico, 2013-03-11 20:35:44]

On 2013/03/11 20:33:23, kal wrote:
> On 2013/03/11 17:14:40, Nico wrote:
> > Thanks for the patch! This looks really good.
> > 
> > Can you add a few tests? We don't have any ios tests yet, you can add
test/ios
> > for this. Please also add tests for the -std=c++11, -stdlib=libc++ flags. A
> test
> > for Wconstant-conversion is nice to have, but not required.
> > 
> > The main point of the tests is to make sure that defaults match xcodebuilds
> > behavior. You can run the mac tests with `python gyptest.py test/mac`. Pass
> `-a`
> > instead of a directory to run all tests. You can also pass `-f
generatorname`
> to
> > run only some generators (`-f ninja,xcode` for example).
> > 
> > https://codereview.chromium.org/12725005/diff/1/pylib/gyp/xcode_emulation.py
> > File pylib/gyp/xcode_emulation.py (right):
> > 
> >
>
https://codereview.chromium.org/12725005/diff/1/pylib/gyp/xcode_emulation.py#...
> > pylib/gyp/xcode_emulation.py:224: job = subprocess.Popen(['xcodebuild',
> > '-version', '-sdk', sdk, infoitem],
> > Nice!
> > 
> >
>
https://codereview.chromium.org/12725005/diff/1/pylib/gyp/xcode_emulation.py#...
> > pylib/gyp/xcode_emulation.py:229: print out
> > Isn't `err` more interesting?
> 
> Err, yes 'err' should be more interesting :) I'll change that.
> 
> How does this work, if I want to make a change or add tests? I'm using git.
How
> to I upload a change/update patch to this same issue?

I think in the git workflow you associate a branch with an issue, and `git cl
upload` uploads all changes on the current branch. (You can use `git cl issue`
to see the issue associated with the current branch, you can run `git cl issue
0` to disassociate the current branch, and you can run `git cl issue 12725005`
on a new branch to associate that branch with this issue. The issue is just
stored in .git/config)

[kal, 2013-03-11 21:14:31]

On 2013/03/11 20:35:44, Nico wrote:
> On 2013/03/11 20:33:23, kal wrote:
> > On 2013/03/11 17:14:40, Nico wrote:
> > > Thanks for the patch! This looks really good.
> > > 
> > > Can you add a few tests? We don't have any ios tests yet, you can add
> test/ios
> > > for this. Please also add tests for the -std=c++11, -stdlib=libc++ flags.
A
> > test
> > > for Wconstant-conversion is nice to have, but not required.
> > > 
> > > The main point of the tests is to make sure that defaults match
xcodebuilds
> > > behavior. You can run the mac tests with `python gyptest.py test/mac`.
Pass
> > `-a`
> > > instead of a directory to run all tests. You can also pass `-f
> generatorname`
> > to
> > > run only some generators (`-f ninja,xcode` for example).
> > > 
> > >
https://codereview.chromium.org/12725005/diff/1/pylib/gyp/xcode_emulation.py
> > > File pylib/gyp/xcode_emulation.py (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/12725005/diff/1/pylib/gyp/xcode_emulation.py#...
> > > pylib/gyp/xcode_emulation.py:224: job = subprocess.Popen(['xcodebuild',
> > > '-version', '-sdk', sdk, infoitem],
> > > Nice!
> > > 
> > >
> >
>
https://codereview.chromium.org/12725005/diff/1/pylib/gyp/xcode_emulation.py#...
> > > pylib/gyp/xcode_emulation.py:229: print out
> > > Isn't `err` more interesting?
> > 
> > Err, yes 'err' should be more interesting :) I'll change that.

Actually, it is already printing stderr. The 'stderr=subprocess.STDOUT' part
should make 'out' get both stdout and stderr. I suppose 'out' could be renamed
'outerr' or something.

> > 
> > How does this work, if I want to make a change or add tests? I'm using git.
> How
> > to I upload a change/update patch to this same issue?
> 
> I think in the git workflow you associate a branch with an issue, and `git cl
> upload` uploads all changes on the current branch. (You can use `git cl issue`
> to see the issue associated with the current branch, you can run `git cl issue
> 0` to disassociate the current branch, and you can run `git cl issue 12725005`
> on a new branch to associate that branch with this issue. The issue is just
> stored in .git/config)

[kal, 2013-03-12 13:10:08]

I have added some tests.

Open issues:

+ File 'check-version-min.c' is used in both test/ios/deployment-target and
test/mac/deployment-target. How can I share that file between two tests under
different directories? I would like to put that single file under third
directory: test/apple.

+ Many of the tests fail with the ninja generator because it tries to use
gcc/g++ explicitly which seems pretty broken compiling for iOS. The make
generator OTOH uses cc/c++ which are symlinks to clang/clang++.

+ Trying to use the 'xcode' generator for ios yields error:
target specifies product type 'com.apple.product-type.tool', but there's no such
product type for the 'iphoneos' platform. This appears to be a bug with this
generator.

https://codereview.chromium.org/12725005/diff/1/pylib/gyp/xcode_emulation.py
File pylib/gyp/xcode_emulation.py (right):

https://codereview.chromium.org/12725005/diff/1/pylib/gyp/xcode_emulation.py#...
pylib/gyp/xcode_emulation.py:229: print out
On 2013/03/11 17:14:40, Nico wrote:
> Isn't `err` more interesting?

'out' gets both stdout and stderr from xcodebuild.
renamed 'err' => 'nul' so its less confusing.

[Sam Clegg, 2013-03-12 19:06:24]

https://codereview.chromium.org/12725005/diff/9001/pylib/gyp/xcode_emulation.py
File pylib/gyp/xcode_emulation.py (right):

https://codereview.chromium.org/12725005/diff/9001/pylib/gyp/xcode_emulation....
pylib/gyp/xcode_emulation.py:227: out, nul = job.communicate()
The convention here is to use '_' for variables that you don't use.

Or you should do:  out = job.communicate()[0]

https://codereview.chromium.org/12725005/diff/9001/pylib/gyp/xcode_emulation....
pylib/gyp/xcode_emulation.py:228: if job.returncode != 0:
Just "if job.retruncode:" is generally considered more pythonic.

https://codereview.chromium.org/12725005/diff/9001/pylib/gyp/xcode_emulation....
pylib/gyp/xcode_emulation.py:230: raise Exception('Error %d running xcodebuild'
% job.returncode)
Use GypError() rather than Exception().   Most exceptions generate backtraces on
the users console.  GypError() is caught and presented without a backtrace.

[kal, 2013-03-12 23:07:23]

Made changes suggested by Sam.

https://codereview.chromium.org/12725005/diff/9001/pylib/gyp/xcode_emulation.py
File pylib/gyp/xcode_emulation.py (right):

https://codereview.chromium.org/12725005/diff/9001/pylib/gyp/xcode_emulation....
pylib/gyp/xcode_emulation.py:227: out, nul = job.communicate()
On 2013/03/12 19:06:24, Sam Clegg wrote:
> The convention here is to use '_' for variables that you don't use.
> 
> Or you should do:  out = job.communicate()[0]
FIXED

https://codereview.chromium.org/12725005/diff/9001/pylib/gyp/xcode_emulation....
pylib/gyp/xcode_emulation.py:230: raise Exception('Error %d running xcodebuild'
% job.returncode)
On 2013/03/12 19:06:24, Sam Clegg wrote:
> Use GypError() rather than Exception().   Most exceptions generate backtraces
on
> the users console.  GypError() is caught and presented without a backtrace.
FIXED.

[kal, 2013-03-13 17:36:51]

Changes:
+ mv test/xcode/* test/mac/
+ Changed test/ios/deployment-target to build as 'static_library'.

The error:
target specifies product type 'com.apple.product-type.tool', but there's no such
product type for the 'iphoneos' platform

is what happens if you try to use xcode to build a normal program w/o a bundle
for iOS. iOS of couse only supports running code-signed bundles. The fix is
simply to add 'mac_bundle': '1' option to the gyp target. Simply doing this gave
me an error though about not being able to find a valid signing identity. I have
changed the ios test to avoid these problems by making the target type
'static_library'.

So now all these tests pass for me with xcode/make generators.

[Nico, 2013-03-13 17:45:25]

LGTM

Have you signed https://developers.google.com/open-source/cla/individual ?

Once you've done this, I'm happy to land this CL. Thanks again!

(if you don't mind me asking: what is this for?)

https://codereview.chromium.org/12725005/diff/28001/pylib/gyp/xcode_emulation.py
File pylib/gyp/xcode_emulation.py (right):

https://codereview.chromium.org/12725005/diff/28001/pylib/gyp/xcode_emulation...
pylib/gyp/xcode_emulation.py:245: # TODO: Implement this better?
nit: remove this TODO, it's not actionable and mysterious

[kal, 2013-03-13 18:02:07]

On 2013/03/13 17:45:25, Nico wrote:
> LGTM
> 
> Have you signed https://developers.google.com/open-source/cla/individual ?

I have now :)

> 
> Once you've done this, I'm happy to land this CL. Thanks again!

Cool thanks!

> 
> (if you don't mind me asking: what is this for?)

I am experimenting building Skia for iOS (with make). These are part of the
changes I made to get it to work.

> 
>
https://codereview.chromium.org/12725005/diff/28001/pylib/gyp/xcode_emulation.py
> File pylib/gyp/xcode_emulation.py (right):
> 
>
https://codereview.chromium.org/12725005/diff/28001/pylib/gyp/xcode_emulation...
> pylib/gyp/xcode_emulation.py:245: # TODO: Implement this better?
> nit: remove this TODO, it's not actionable and mysterious

[kal, 2013-03-13 18:04:19]

On 2013/03/13 18:02:07, kal wrote:
> On 2013/03/13 17:45:25, Nico wrote:
> > LGTM
> > 
> > Have you signed https://developers.google.com/open-source/cla/individual ?
> 
> I have now :)
> 
> > 
> > Once you've done this, I'm happy to land this CL. Thanks again!
> 
> Cool thanks!
> 
> > 
> > (if you don't mind me asking: what is this for?)
> 
> I am experimenting building Skia for iOS (with make). These are part of the
> changes I made to get it to work.
> 
> > 
> >
>
https://codereview.chromium.org/12725005/diff/28001/pylib/gyp/xcode_emulation.py
> > File pylib/gyp/xcode_emulation.py (right):
> > 
> >
>
https://codereview.chromium.org/12725005/diff/28001/pylib/gyp/xcode_emulation...
> > pylib/gyp/xcode_emulation.py:245: # TODO: Implement this better?
> > nit: remove this TODO, it's not actionable and mysterious

There is still the issue of check-version-min.c being twice in repo. They should
really both share the test/mac version if possible. But I couldn't get it to
work. Maybe you will have more luck?

[Nico, 2013-03-18 15:17:05]

https://codereview.chromium.org/12725005/diff/28001/pylib/gyp/xcode_emulation.py
File pylib/gyp/xcode_emulation.py (right):

https://codereview.chromium.org/12725005/diff/28001/pylib/gyp/xcode_emulation...
pylib/gyp/xcode_emulation.py:226: job = subprocess.Popen(['xcodebuild',
'-version', '-sdk', sdk, infoitem],
As it turns out, this doesn't work with Xcode 4.2:

$ xcodebuild -version
Xcode 4.2
Build version 4C199
$ xcodebuild -version -sdk 10.6 
xcodebuild: error: SDK "10.6" cannot be located.

Yet:
$ ls /Developer/SDKs/MacOSX10.6.sdk/
Developer		Library			SDKSettings.plist	System			usr

[Nico, 2013-03-18 15:32:31]

https://codereview.chromium.org/12725005/diff/28001/pylib/gyp/xcode_emulation.py
File pylib/gyp/xcode_emulation.py (right):

https://codereview.chromium.org/12725005/diff/28001/pylib/gyp/xcode_emulation...
pylib/gyp/xcode_emulation.py:226: job = subprocess.Popen(['xcodebuild',
'-version', '-sdk', sdk, infoitem],
On 2013/03/18 15:17:05, Nico wrote:
> As it turns out, this doesn't work with Xcode 4.2:
> 
> $ xcodebuild -version
> Xcode 4.2
> Build version 4C199
> $ xcodebuild -version -sdk 10.6 
> xcodebuild: error: SDK "10.6" cannot be located.
> 
> Yet:
> $ ls /Developer/SDKs/MacOSX10.6.sdk/
> Developer		Library			SDKSettings.plist	System			usr

Durr, it works if you say "macosx10.6" instead of "10.6". Sorry, ignore me.

https://codereview.chromium.org/12725005/diff/28001/test/mac/gyptest-clang-cx...
File test/mac/gyptest-clang-cxx-library.py (right):

https://codereview.chromium.org/12725005/diff/28001/test/mac/gyptest-clang-cx...
test/mac/gyptest-clang-cxx-library.py:18: test.run_gyp('clang-cxx-library.gyp',
chdir='clang-cxx-library')
This test needs something like

  if not os.path.isdir('/usr/lib/c++'):
    return

It looks like Xcode 4.2 on 10.6 doesn't install libc++, at least not in the
place clang expects it (and where it is with later versions):

$ clang -v
# …
ignoring nonexistent directory "/usr/include/c++/v1"
ignoring nonexistent directory "/usr/local/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/bin/../lib/clang/3.0/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)


I can't think of a better fix than skipping this test if it doesn't exist (which
means the test won't run on our bots at the moment, but oh well).

[kal, 2013-03-18 15:32:32]

https://codereview.chromium.org/12725005/diff/28001/pylib/gyp/xcode_emulation.py
File pylib/gyp/xcode_emulation.py (right):

https://codereview.chromium.org/12725005/diff/28001/pylib/gyp/xcode_emulation...
pylib/gyp/xcode_emulation.py:226: job = subprocess.Popen(['xcodebuild',
'-version', '-sdk', sdk, infoitem],
On 2013/03/18 15:17:05, Nico wrote:
> As it turns out, this doesn't work with Xcode 4.2:
> 
> $ xcodebuild -version
> Xcode 4.2
> Build version 4C199
> $ xcodebuild -version -sdk 10.6 
> xcodebuild: error: SDK "10.6" cannot be located.
> 
> Yet:
> $ ls /Developer/SDKs/MacOSX10.6.sdk/
> Developer		Library			SDKSettings.plist	System			usr

The SDK name is "macosx10.6". "10.6" is not a valid SDK name with any version of
Xcode.

[Nico, 2013-04-12 20:28:39]

https://codereview.chromium.org/12725005/diff/28001/pylib/gyp/xcode_emulation.py
File pylib/gyp/xcode_emulation.py (right):

https://codereview.chromium.org/12725005/diff/28001/pylib/gyp/xcode_emulation...
pylib/gyp/xcode_emulation.py:226: job = subprocess.Popen(['xcodebuild',
'-version', '-sdk', sdk, infoitem],
Zombie thread: Why do you redirect stderr at all?

We just had some confusion because xcodebuild would error out:

https://gist.github.com/5374843

"""xcodebuild[39147:f07] Error loading
/Users/alexisme/Library/Developer/Xcode/Third-Party
Plug-ins/CodePilot2.xcplugin/Contents/MacOS/CodePilot2: 
dlopen(/Users/alexisme/Library/Developer/Xcode/Third-Party
Plug-ins/CodePilot2.xcplugin/Contents/MacOS/CodePilot2, 265): Symbol not found:
_IDEEditorDocumentDidChangeNotification
  Referenced from: /Users/alexisme/Library/Developer/Xcode/Third-Party
Plug-ins/CodePilot2.xcplugin/Contents/MacOS/CodePilot2
  Expected in: flat namespace
 in /Users/alexisme/Library/Developer/Xcode/Third-Party
Plug-ins/CodePilot2.xcplugin/Contents/MacOS/CodePilot2
2013-04-12 17:18:59.804 xcodebuild[39147:f07] WARNING: Failed to load plugin at:
/Users/alexisme/Library/Developer/Xcode/Third-Party
Plug-ins/CodePilot2.xcplugin, skipping.  Could not load bundle.
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk"""

…which silently got copied into the sdk version output, which then later caused
an assertion about a newline being in some env var string. What's the downside
of not redirecting stderr?

(Weird that this didn't cause a nonzero exit code though.)

[kal, 2013-04-12 22:16:38]

On 2013/04/12 20:28:39, Nico wrote:
>
https://codereview.chromium.org/12725005/diff/28001/pylib/gyp/xcode_emulation.py
> File pylib/gyp/xcode_emulation.py (right):
> 
>
https://codereview.chromium.org/12725005/diff/28001/pylib/gyp/xcode_emulation...
> pylib/gyp/xcode_emulation.py:226: job = subprocess.Popen(['xcodebuild',
> '-version', '-sdk', sdk, infoitem],
> Zombie thread: Why do you redirect stderr at all?
> 
> We just had some confusion because xcodebuild would error out:
> 
> https://gist.github.com/5374843
> 
> """xcodebuild[39147:f07] Error loading
> /Users/alexisme/Library/Developer/Xcode/Third-Party
> Plug-ins/CodePilot2.xcplugin/Contents/MacOS/CodePilot2: 
> dlopen(/Users/alexisme/Library/Developer/Xcode/Third-Party
> Plug-ins/CodePilot2.xcplugin/Contents/MacOS/CodePilot2, 265): Symbol not
found:
> _IDEEditorDocumentDidChangeNotification
>   Referenced from: /Users/alexisme/Library/Developer/Xcode/Third-Party
> Plug-ins/CodePilot2.xcplugin/Contents/MacOS/CodePilot2
>   Expected in: flat namespace
>  in /Users/alexisme/Library/Developer/Xcode/Third-Party
> Plug-ins/CodePilot2.xcplugin/Contents/MacOS/CodePilot2
> 2013-04-12 17:18:59.804 xcodebuild[39147:f07] WARNING: Failed to load plugin
at:
> /Users/alexisme/Library/Developer/Xcode/Third-Party
> Plug-ins/CodePilot2.xcplugin, skipping.  Could not load bundle.
>
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk"""
> 
> …which silently got copied into the sdk version output, which then later
caused
> an assertion about a newline being in some env var string. What's the downside
> of not redirecting stderr?
> 
> (Weird that this didn't cause a nonzero exit code though.)

They were redirected so that stdout/stderr could be printed out interleaved
together on error (non-zero exit code). I was unaware of cases like this with
this tool.

Now I think its better not to redirect stderr then at all. I don't think there
is any downside (only upside).

[kal, 2013-04-12 22:24:24]

On 2013/04/12 20:28:39, Nico wrote:
>
https://codereview.chromium.org/12725005/diff/28001/pylib/gyp/xcode_emulation.py
> File pylib/gyp/xcode_emulation.py (right):
> 
>
https://codereview.chromium.org/12725005/diff/28001/pylib/gyp/xcode_emulation...
> pylib/gyp/xcode_emulation.py:226: job = subprocess.Popen(['xcodebuild',
> '-version', '-sdk', sdk, infoitem],
> Zombie thread: Why do you redirect stderr at all?
> 
> We just had some confusion because xcodebuild would error out:
> 
> https://gist.github.com/5374843
> 
> """xcodebuild[39147:f07] Error loading
> /Users/alexisme/Library/Developer/Xcode/Third-Party
> Plug-ins/CodePilot2.xcplugin/Contents/MacOS/CodePilot2: 
> dlopen(/Users/alexisme/Library/Developer/Xcode/Third-Party
> Plug-ins/CodePilot2.xcplugin/Contents/MacOS/CodePilot2, 265): Symbol not
found:
> _IDEEditorDocumentDidChangeNotification
>   Referenced from: /Users/alexisme/Library/Developer/Xcode/Third-Party
> Plug-ins/CodePilot2.xcplugin/Contents/MacOS/CodePilot2
>   Expected in: flat namespace
>  in /Users/alexisme/Library/Developer/Xcode/Third-Party
> Plug-ins/CodePilot2.xcplugin/Contents/MacOS/CodePilot2
> 2013-04-12 17:18:59.804 xcodebuild[39147:f07] WARNING: Failed to load plugin
at:
> /Users/alexisme/Library/Developer/Xcode/Third-Party
> Plug-ins/CodePilot2.xcplugin, skipping.  Could not load bundle.
>
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk"""
> 
> …which silently got copied into the sdk version output, which then later
caused
> an assertion about a newline being in some env var string. What's the downside
> of not redirecting stderr?
> 
> (Weird that this didn't cause a nonzero exit code though.)

I think the zero exit code makes sense because this is a non-fatal error. The
last line of output seems to be the correct stdout value?

[Nico, 2013-04-12 22:31:53]

On 2013/04/12 22:24:24, kal wrote:
> On 2013/04/12 20:28:39, Nico wrote:
> >
>
https://codereview.chromium.org/12725005/diff/28001/pylib/gyp/xcode_emulation.py
> > File pylib/gyp/xcode_emulation.py (right):
> > 
> >
>
https://codereview.chromium.org/12725005/diff/28001/pylib/gyp/xcode_emulation...
> > pylib/gyp/xcode_emulation.py:226: job = subprocess.Popen(['xcodebuild',
> > '-version', '-sdk', sdk, infoitem],
> > Zombie thread: Why do you redirect stderr at all?
> > 
> > We just had some confusion because xcodebuild would error out:
> > 
> > https://gist.github.com/5374843
> > 
> > """xcodebuild[39147:f07] Error loading
> > /Users/alexisme/Library/Developer/Xcode/Third-Party
> > Plug-ins/CodePilot2.xcplugin/Contents/MacOS/CodePilot2: 
> > dlopen(/Users/alexisme/Library/Developer/Xcode/Third-Party
> > Plug-ins/CodePilot2.xcplugin/Contents/MacOS/CodePilot2, 265): Symbol not
> found:
> > _IDEEditorDocumentDidChangeNotification
> >   Referenced from: /Users/alexisme/Library/Developer/Xcode/Third-Party
> > Plug-ins/CodePilot2.xcplugin/Contents/MacOS/CodePilot2
> >   Expected in: flat namespace
> >  in /Users/alexisme/Library/Developer/Xcode/Third-Party
> > Plug-ins/CodePilot2.xcplugin/Contents/MacOS/CodePilot2
> > 2013-04-12 17:18:59.804 xcodebuild[39147:f07] WARNING: Failed to load plugin
> at:
> > /Users/alexisme/Library/Developer/Xcode/Third-Party
> > Plug-ins/CodePilot2.xcplugin, skipping.  Could not load bundle.
> >
>
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk"""
> > 
> > …which silently got copied into the sdk version output, which then later
> caused
> > an assertion about a newline being in some env var string. What's the
downside
> > of not redirecting stderr?
> > 
> > (Weird that this didn't cause a nonzero exit code though.)
> 
> I think the zero exit code makes sense because this is a non-fatal error. The
> last line of output seems to be the correct stdout value?

Looks like it. I sent you https://codereview.chromium.org/14163004/ to remove
the stderr piping.