search

aeppert / gyp

Automatically exported from code.google.com/p/gyp
0 stars 0 forks source link

gyp errors out when xcode-select returns no path #292

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Take a fresh install of OS X 10.7 or newer.
2. Install the Command Line Tools package from connect.apple.com

What is the expected output? What do you see instead?

Expected:

gyp can configure projects that build using the Frameworks and compilers 
contained in the Command Line Tools package.

Result:

gyp throws an error from _GetSdkBaseDir in pylib/gyp/xcode_emulation.py and 
quits because no allowance is made for xcode-select returning a nonzero exit 
code. xcode-select returns 1 when no path has been set, which is normal for a 
CLT-only setup as there is no /Developer folder or XCode.app to set the path to.

What version of the product are you using? On what operating system?

The error showed up in r1237 and is very prominent when building Node.js. 
Version 0.8.1 of Node, which used gyp r1214 builds just fine under a CLT-only 
setup. Version 0.8.2, which upgraded to gyp r1426 fails to build.

It should be noted that setting a completely bogus path using `xcode-select 
-switch some_dir_that_exists_but_doesnt_contain_anything` allows gyp to 
configure and build Node just fine because xcode-select returns a zero exit 
code in this case.

Please provide any additional information below.

See the following issue on GitHub for more info:

https://github.com/joyent/node/issues/3681

Original issue reported on code.google.com by charles....@gmail.com on 25 Aug 2012 at 8:02

GoogleCodeExporter commented 9 years ago 
It should also be noted that:

  - The xcodebuild tool is completely no-functional when just the Command Line Tools are installed.

  - Using xcode-select to set a bogus path results in xcodebuild hanging in an infinite loop rather than reporting to the user that it is non-functional.

Original comment by charles....@gmail.com on 25 Aug 2012 at 8:07

GoogleCodeExporter commented 9 years ago 
Also, this can be re-produced on a non-fresh install by unsetting the 
xcode-select path. This can be accomplished by moving or removing the contents 
of `/usr/share/xcode-select/`.

Original comment by charles....@gmail.com on 28 Aug 2012 at 5:22

GoogleCodeExporter commented 9 years ago 
Basically this bug means gyp depends on xcode when not all projects need it.  
Now that Mac has released the Xcode developer tools, would be nice if Gyp would 
respect that instead of blowing up if xcode-select doesn't exist.

Original comment by ankurset...@gmail.com on 2 Feb 2013 at 4:13

GoogleCodeExporter commented 9 years ago 
Now that gyp has switched to using xcodebuild instead of xcode-select, the 
workaround of setting the DEVELOPER_DIR environment variable no longer works at 
all. The xcodebuild script that comes with the OS is just a shim, and the 
Command Line Tools don't ship the real version of xcodebuild.

Hence - CLT-only users can't build any gyp projects ATM. This affects node, as 
one example, which doesn't actually require Xcode to build but which fails to 
configure under gyp.

Original comment by mistyde...@gmail.com on 22 Apr 2013 at 6:26

GoogleCodeExporter commented 9 years ago 
Please fix this for CLT users.

Original comment by dylan.verheul on 24 Apr 2013 at 4:58

GoogleCodeExporter commented 9 years ago 
Fix submitted: https://codereview.chromium.org/14887003

Original comment by mistyde...@gmail.com on 3 May 2013 at 12:49

GoogleCodeExporter commented 9 years ago 
Could this patch please be accepted? This is still blocking node installs when 
XCode is not present. As I mention on the original node.js ticket I was able to 
cleanly work around the problem by applying this patch: 
https://github.com/joyent/node/issues/3681

Original comment by d...@dbsgeo.com on 23 Aug 2013 at 2:48

GoogleCodeExporter commented 9 years ago 
Anyone know the timeline of when this might be accepted or if it needs more 
work?

Original comment by d...@dbsgeo.com on 17 Sep 2013 at 1:58

GoogleCodeExporter commented 9 years ago 
Hi, I was able to verify that this patch fixed an issue I was having while 
trying to compile a large OS project which had a submodule which uses gyp. 
Would it be possible for someone from gyp to review this patch and/or consider 
accepting it? Thanks! :)

Original comment by eric.sam...@gmail.com on 7 Oct 2013 at 2:20

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
This is now fixed in r1819.

Original comment by mistyde...@gmail.com on 16 Dec 2013 at 10:35

GoogleCodeExporter commented 9 years ago 
The patch was reverted, but has landed again in r1825. A second patch to fix 
Xcode version detection is incoming.

Original comment by mistyde...@gmail.com on 24 Dec 2013 at 10:08

GoogleCodeExporter commented 9 years ago 

Many of the patches to gyp mentioned above didn't work for me. I managed to get 
this to work. In case any of you are still having problems, here's what I did:

I noticed that the source code for gyp is trying to run xcodebuild, but if 
xcodebuild fails, then gyp fails. However, there is error handling in gyp in 
case xcodebuild runs successfully, but returns something other than expected. 
Relying on the behavior of gyp as described, I created an executable file 
called xcodebuild and put it in my search path. Here are its contents:

#!/bin/bash

exit 0

That's it. All I wanted to do was make sure that gyp doesn't freak out when it 
tries to run xcodebuild. I did not touch xcode-select or the gyp source.

This will probably break badly if there is a project that depends on Xcode, 
though...

Original comment by James.G....@gmail.com on 3 Feb 2014 at 4:12