Skip to content
This repository

Support for Xcode 4.3 #9179

Closed
xose opened this Issue December 18, 2011 · 225 comments
José Martínez

The upcoming Xcode 4.3 release will be distributed as a self-contained application bundle. It will no longer require an extra installation step for easy distribution and faster delta updates on the AppStore. This means that command line tools will NOT be installed on /usr/bin and SDKs/headers/related tools will not be on /Developer, so Homebrew should be updated with the new paths.

On a default installation of Xcode, the new location of the command line tools will be /Applications/Xcode.app/Contents/Developer/usr/bin. This includes the compilers, as well as git, svn and other development tools. Other references to /Developer on Homebrew and the formulae should also be updated.

There is already a xcode_prefix function on Homebrew/utils.rb that works great for finding the correct Developer folder on Xcode 4.3. It just needs to be used for the compiler paths, git and other tools, and the formulae that reference /Developer.

camillol

They could still symlink stuff when you launch Xcode... they don't even do that?

Charlie Sharpsteen
Owner

I don't think any of the core team has access to developer previews of XCode. So there is not much we can do until we get our hands on a copy of XCode.app to see what the new paths are.

José Martínez

For previous versions of Xcode, this can be tested by deselecting the "UNIX Development" package during installation, or uninstalling it with sudo /Developer/Library/uninstall-devtools --mode=unixdev. If Homebrew works without requiring the UNIX tools to be installed, it will work fine on Xcode 4.3.

The correct path is already provided by xcode_prefix in utils.rb. The tools are located in {xcode_prefix}/usr/bin, no matter which version of Xcode is installed.

I tried to fix it myself, but I'm not familiar with the internals. The compiler paths are easy to update, as well as formulae that hardcode the path. But there are way too many calls to git with no path, and there may be other required changes that I'm not aware of.

They could still symlink stuff when you launch Xcode... they don't even do that?

The first time you launch Xcode it will request to install a couple packages, but not the UNIX tools.

Jack Nagel
Owner

there are way too many calls to git with no path

FYI, we don't hard code the path to git because we still support OS X / XCode combinations that did not ship with git.

Adam Vandenberg
Owner

Is there at least a link to a reference on these changes?

John Harrison

I just downloaded Xcode 4.3.

It does say the following in the release notes:

This preview release does not include Unix development tools placed into /usr. To perform makefile- based and config-based builds, either install Xcode 4.2.1 or use xcrun to execute the tools provided within Xcode.

I do not know if this means the final release will not include the Unix development tools placed in /usr or not, but I'd be happy to test anything out that needs testing since I do have Xcode 4.3 developer preview 2 installed.

Charlie Sharpsteen
Owner

If Homebrew works without requiring the UNIX tools to be installed, it will work fine on Xcode 4.3.

Most tasks executed by Homebrew require the UNIX tools. Because of this, it will be hard to make progress without a copy of XCode 4.3 to test against.

camillol

I think we should simply ask users to add /Applications/Xcode.app/Contents/Developer/usr/bin to their PATH in .profile. Maybe provide a script to do it.

Jack Nagel
Owner

We can probably use xcrun in some capacity. Though it is really slow with a cold cache.

José Martínez

Most tasks executed by Homebrew require the UNIX tools. Because of this, it will be hard to make progress without a copy of XCode 4.3 to test against.

UNIX tools have always been installed with Xcode in Developer. Until now there was an optional installation of a duplicate of the tools in /usr, but this is no longer the case on Xcode 4.3.

I don't know how will Apple handle the updates from 4.2, but the tools in /usr might be stuck with the current version and never updated again, so they shouldn't be relied upon. There is always a copy of the tools in Developer which is guaranteed to be the latest version.

I think we should simply ask users to add /Applications/Xcode.app/Contents/Developer/usr/bin to their PATH in .profile. Maybe provide a script to do it.

This will not fix anything, compilers and other tools still use absolute paths in Homebrew.


There is also a new Toolchains directory for pluggable toolchains (compiler, assembler, linker, ...). Clang and related tools have been moved there, LLVM and other UNIX tools remain on Developer.

Here is a file listing of the new Developer folder, as well as the Toolchains folder on DP2: https://gist.github.com/1502152

Mike McQuaid
Owner

We should do the smart thing and auto detect the path when we have access to 4.3. This should not require any manual user intervention.

John Harrison

xcode-select -print-path can be used print the path to the current version of Xcode, just so you know.

John Harrison

So, I made a VM with OS X 10.7.2 and Xcode 4.3 installed and nothing else. Some thing worth noting:

  • /Applications/Xcode.app/Contents/Developer/usr/bin has a lot of things, but not clang, ld, nm, etc. Note, this directory contains a symbolic link 'cc -> clang' and 'c++ -> clang++' but clang isn't in that directory and they are not absolute paths to the location of the actual clang executable's location.
  • /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin contains clang, ld, nm, etc.

This is causing problems in brew because of all of the hard coded paths (eg. /usr/bin/clang , /usr/bin/cc , /usr/bin/gcc , etc.)

If there is anything specific you guys want me to test let me know, but I can tell a number of hard coded paths will need to be updated for Xcode 4.3 to work.

José Martínez

This is the file listing as of Xcode 4.3 DP3: https://gist.github.com/1591451

Notable changes:

  • Autotools are gone! autoconf/automake and all related tools have been removed from Xcode.
  • bison/yacc and m4 have been moved to Toolchains.
  • cc and c++ symlinks are now on Toolchains too.
Jack Nagel
Owner

Autotools are gone! autoconf/automake and all related tools have been removed from Xcode.

That's really disappointing.

Jack Nagel
Owner

Can I get a list of things that XCode 4.3 _does_ put in /usr/bin? Is there anything other than xcrun?

José Martínez

These are the only files installed/updated to /usr/bin on first run: https://gist.github.com/1592925

Those ~1000 bytes files are actually scripts that call xcode-select to find the proper Xcode folder, and then run the tool.

Mike McQuaid
Owner

So it's released. I'm going to try and sort it.

Samuel John
  • First I called sudo /Library/Developer/Shared/uninstall-devtools to get a clean start.
  • Then no gcc nor clang or whatever was in my path
  • Installed XCode 4.3 from App store. Launched it for the first time and restarted my Mac.
  • Still no gcc nor clang in my path.
  • xcode-select -print-path tells me I have not selected any Xcode.
  • So I did sudo xcode-select -select /Applications/Xcode.app/Contents/Developer/. I hope this is just a bug and not everyone has to do this. Perhaps Apple forgot to set this on install?
  • Now I can find gcc and clang and the other with xcrun -find <toolname>
$ xcrun -find gcc
/Applications/Xcode.app/Contents/Developer/usr/bin/gcc
$ xcrun -find clang
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang

Is this the way to go?
Do you also have to teach xcode-select manually about the location?

José Martínez

The command line tools can now be installed manually: Xcode > Preferences > Downloads > Components

Sorin Ionescu

I'm investigating Xcode 4.3 to see if gcc-without-xcode is still relevant. Where before programs were compiled to be run from /usr/bin, now, I suspect, that they can only be run from /Applications/Xcode.app/Contents/Developer/usr/bin/ and /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ respectively, and they cannot be copied to /usr/bin. Hence why Xcode installs those dummy scripts in /usr/bin.

I am leaning towards depending on Xcode 4.3 for the SDK headers only and installing our own gcc, autotools, etc.

Sorin Ionescu

@xose Is it actually installing the tools or dummy scripts that in turn call the command line tools in the Xcode application directory?

Konstantin Shabanov

https://developer.apple.com/downloads/index.action#
Didn't tried yet, but "Command line tools for Xcode" is the only package needed at the moment.

It could be downloaded directly or installed from xcode download section in preferences.

Samuel John

@xose and @etehtsea you need a Developer ID to download these. That's no way to go.
I cannot even open the package to see it's contents.

Resorting to xcrun is better in my opinion.

My question to you would be, if xcode-select -print-path does this right out of the box, or did you need to "-switch" it first?

Sorin Ionescu

I have had a look in command_line_tools_for_xcode_.dmg that can be downloaded from @etehtsea's link.

The good news is that they have not yet removed llvm-gcc4.2.pkg since not everything compiles with clang. The bad news is that they have indeed removed Autotools.

gcc-without-xcode still seems relevant since there is no uninstall script in the disk image.

Present Packages

  • BluetoothSDK.pkg
  • clang.pkg
  • CoreAudioSDK.pkg
  • DeveloperToolsCLI.pkg
  • DevSDK.pkg
  • FireWireSDK.pkg
  • JavaSDK.pkg
  • llvm-gcc4.2.pkg
  • OpenGLSDK.pkg
  • QuickTimeSDK.pkg
  • WebKitSDK.pkg
  • X11Documentation.pkg
  • X11SDK.pkg

Missing Packages

  • DeveloperToolsSystemSupport.pkg
  • DistributedBuildsSupport.pkg
Jack Nagel
Owner

xcode download section in preferences.

Does this mean any Xcode 4.3 user can install the UNIX tools from preferences?

Resorting to xcrun is better in my opinion.

I messed around with this and xcrun is just painfully slow on a cold cache. It will make everything in Homebrew lag.

The best solution (short of finding a way to install the dev tools in their proper location) is to maintain an internal list of paths where the tools are found, and use a wrapper method that calls system with a custom PATH.

Mike McQuaid
Owner

Yep, seems reasonable @jacknagel. Will have a look at this later. Requiring preferences or intervention like that is a pain. At least the App Store defaults to installing Xcode in the same place.

Mike McQuaid
Owner

I've done a full developer uninstall first so I'll see what explodes.

Jack Nagel
Owner

And it would be pretty uninvasive, we could just patch our system methods to use this PATH and everything should "just work" (short of autotools, I guess).

Mike McQuaid
Owner

@jacknagel Adding /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin and /Applications/Xcode.app/Contents/Developer/usr/bin to the PATH might be sufficient.

Mike McQuaid
Owner

And for autotools just make them keg-only.

Mike McQuaid
Owner

Well, perhaps optionally keg-only only on non Xcode 4.3 installs. If we can't do that we perhaps should add the functionality.

Jack Nagel
Owner

I think keg-only is "good enough", Xcode 4.3 users who want to use them can always brew link them. And most people who use them for development have newer versions installed already anyway.

Sorin Ionescu

@jacknagel I'm still downloading Xcode 4.3, but from my understanding right now is that in does not install the tools themselves from preferences but wrapper scripts that point to the location of the tools.

commandline_tools_for_xcode.dmg installs the binaries in /usr/bin just as before. However, there is no uninstall script, and pkgutil --unlink is very dangerous.

command_line_tools_for_xcode.dmg is a 171.7 MB download, which extracts to 479.2 MB of files. xcode_4.3_for_lion.dmg is a 1.84 GB download, which contains Xcode.app that is 3.16 GB.

Max Howell
Owner

I'm fixing this right now, basically I'll just add the tools path to PATH and set CC etc. correctly in the case that /usr/bin/blah don't exist etc. Any concerns please voice them in the next few hours.

Max Howell
Owner

Also, I do have a paid Apple Developer account, so I could have fixed this. Sorry I don't check all threads. I respond to @mxcl most of the time though!

Mike McQuaid
Owner

I think I'll get a paid Apple Developer account too. Can't be worse than Gentoo was ;)

Mike McQuaid
Owner

And cheers @mxcl.

Max Howell
Owner

I need it for all the iOS dev I do, otherwise there isn't much point really. You get some access to upcoming Xcodes, iOS releases, iTunes releases and OS X releases, but it's expensive for that really.

Chad Catlett

@sorin-ionescu Installing from preferences actually downloads and installs command_line_tools_for_xcode.dmg, it actually requires you to sign in with your dev id to pull it down.

Sorin Ionescu

@chadcatlett That's good to know. Does it also allow you to uninstall it?

Chad Catlett

Sadly it does not allow uninstalling, just installing and updating when new releases come out.

Jack Nagel
Owner

Also we'll need to put "update formula that hardcode /usr/bin" on the to-do list.

Max Howell
Owner

I'm also going to add this path to PATH. I figure that'll stop a lot of breakage too.

Max Howell mxcl closed this in 2fab16e February 16, 2012
Max Howell
Owner

I hope I didn't break anything, please review.

Sorin Ionescu

@chadcatlett I'll update gcc-without-xcode then. Clean installation and uninstallation are important to me and others.

Mike McQuaid
Owner

Looks pretty good. Seems anything using CMake is incredibly broken (I'm sure you're surprised to hear). Testing.

Jack Nagel
Owner

Cool.

Though formula that do system "/usr/bin/foo" need to be fixed to just say system "foo", which is what I meant before.

Mike McQuaid
Owner

And QMake. It's going to be a fun time to be a Qt developer ;)

Sorin Ionescu

@jacknagel If there is an Autotools formula in Homebrew-Alt, it should be transplanted to Homebrew and formulas that need it should add it as a dependency.

Jack Nagel
Owner

Yes. This will likely take more than a day though, those formulae need to be audited thoroughly before that happens.

Jack Nagel
Owner

But making them keg-only should work out well, since their bin directories will automatically be prepended to the path.

Kenneth Reitz

Hey guys — I've been working with Apple since the release of my osx-gcc-installer.

I helped them come up with the requirements and command_line_tools_for_xcode is the result of that effort. Apple should be putting a link to it on their open source page soon.

I know there were some reservations about hombrew supporting osx-gcc-installer, but since this is a real Apple product now, made specifically with Hombrew users in mind, we need to do our best to support it. Apple's doing their best to support us.

The only applications that will have trouble are ones that need the proprietary headers (CoreAudio, CoreData, OpenGL, etc). MacVim obviously needs these things, but most software doesn't. There are a few surprises, though: Node, for example, binds to CoreData for some reason.

I think the best approach here is to give formula the ability to say if they need those special headers, and give hombrew the ability to say "hey you need full xcode for this formula".

Sorin Ionescu

@kennethreitz Thank you. The headers for CoreAudio, CoreData, OpenGl, etc. are in command_line_tools_for_xcode.dmg. See the package list I wrote above. Is there someone at Apple we can contact to request an uninstaller? Thank you, again.

Kenneth Reitz

@sorin-ionescu oh seriously? That's even bigger news. I'm installing it now.

Max Howell
Owner

I replied to @kennethreitz's post on the list, so I won't reiterate my thanks here. It's great news for us.

@mikemcquaid my patches added the Xcode 4.3 tools path to PATH so I would have thought that would solve most of the issues? Still discuss your findings with me as I'm sure I can help here.

@jacknagel there is now MacOS.dev_tools_path this is the better option than scanning the path. Stuff that wants gcc though should use ENV.gcc and ENV['CC'] as before. Since gcc is special cased.

@kennethreitz do the tools Apple provide also not have gcc?

Konstantin Shabanov

@mxcl gcc-llvm amd clang-3.1 as I see.

Kenneth Reitz

Wow, they actually included all of the proprietary SDKs. That's a huge surprise! This is incredible.

I have a call with them later today. Let me know if there are any major show-stoppers.

Konstantin Shabanov

Most problem at the moment is:

Pre-release software is Apple confidential information. Your unauthorized distribution of pre-release software or disclosure of information relating to pre-release software (including the posting of screen shots) may subject you to both civil and criminal liability and result in immediate termination of your Membership.

Hope it will be published widely soon.

Kenneth Reitz

That won't be a problem.

Mike McQuaid
Owner

Yeh, that would be great. Nice work @kennethreitz.

Now we have Clang 3.1 we should probably default to that rather than LLVM-GCC.

@mxcl: I'm getting this: https://gist.github.com/1847122 (only until I installed the command-line tools).

Konstantin Shabanov

Now we have Clang 3.1 we should probably default to that rather than LLVM-GCC.

Highly support this idea.

Mike McQuaid
Owner

Installed the command line tools and yey: /usr/bin/cc@ -> clang

Max Howell
Owner

Aren't we asking for trouble? Making a new compiler the default when everything expects GCC (llvm-gcc is close enough right?).

@mikemcquaid fixed. Code path I didn't get for annoying reasons. I think everything else is tested.

Max Howell
Owner

Though admitedly it is the default for the command line tools DMG. Xcode 4.3 doesn't impose a default, it removed the cc symlink altogether.

Sorin Ionescu

@kennethreitz There should not be any show stoppers. All the packages I listed above, except for the two under the missing heading, I used for gcc-without-xcode, and I have never had problems, except with formulae that hard coded paths to /Develper/sdks.

I do not know if the two missing packages are still relevant.

DistributedBuildsSupport.pkg

Distributed compiling is not relevant for most people.

DeveloperToolsSystemSupport.pkg

private/etc/gdb.conf
usr/bin/xcode-select
usr/share/man/man1/xcode-select.1
usr/share/xcode-select

gcc-without-xcode only installed the 4 files above from the aforementioned package. xcode-select is probably no longer relevant, if it still exists. The gdb configuration file may still be needed. Someone who knows gdb well should confirm.

Personal Request

When you call them, ask for an uninstaller, please.

Konstantin Shabanov

Does anywhere exist a list of clang incompatible things?

Teo Ljungberg

I also installed the CLI tools and
gcc:

xcrun -find gcc 
/Developer/usr/bin/gcc

cc:

xcrun -find cc
/Developer/usr/bin/cc

clang:

xcrun -find clang
/Developer/usr/bin/clang

Is there any other other developer-tools-dependencies that homebrew has?

Max Howell
Owner

Okay, clearly I need to adjust my code in some places. Using xcrun, and also there is a cc for Xcode 4.3, xcrun told me, and it defaults to clang. So etc.

I assume xcrun was built for us or the likes of us, so many thanks to Apple for that. Though we still need all the legacy code for Xcode 4.2 and below.

Mike McQuaid
Owner

Yeh, I think if it's the default we should use it. If we don't pick that up we should (I'll do some tests).

Those who are wondering you can download the command line tools from here:
https://developer.apple.com/downloads/index.action#

They are "Command Line Tools for Xcode - February 2012". Hopefully we can get a more friendly (binary) download location but I guess it's no worse than Xcode 3 was.

Kenneth Reitz

Yes, an official release will be available soon. Feedback from Hombrew specifically is important.

I have a call with them in 2 hours. Let me know if there are obvious issues.

Mike McQuaid
Owner

It seems we do pick it up. CC/CXX are set to clang here with no code changes. Nice.

Teo Ljungberg

@mxcl I still have Xcode 4.3 installed and my output is just this

and btw, have git always been apart of the developer tools? I just found it in /Developer/usr/bin

Mike McQuaid
Owner

I uninstalled all the previous developer tools (and the entire /Developer tree) and my output is the same but with /Applications/Xcode.app/Contents/Developer/.

Mike McQuaid
Owner

@kennethreitz The installer looks good to me and works with a few C/C++ packages I tested (gnu-sed git iodine lzz pidof pkg-config readline tree). Thanks so much for helping get this sorted.

Sorin Ionescu

@metamorfos Git has been part of the developer tools recently, but you should still use the one found in Homebrew if you install your own Git plugins and scripts since the Apple Git build, at least the one that came with Xcode 4.2, had trouble finding them. git-subtree, for example, gave me grief.

Mike McQuaid
Owner

@metamorfos Git has been part of the developer tools since Xcode 4.0.

Teo Ljungberg

@mikemcquaid @sorin-ionescu thanks fellas. I guess I havn't been paying attention in a while
I'm keeping both, so no worries there.

OnT: Shouldn't 'we', as in the homebrew community, be able to bundle the Commandline tools into homebrew? Because THAT would be handy as fuck to just be able to:
brew install dev-tools or something to install of the needed programs

Kenneth Reitz

@metamorfos the tools themselves, but not the proprietary headers. Only apple can distribute those.

We could build a tool that downloads and installs the tools after your provide your apple id credentials though.

Mike McQuaid
Owner

A longer-term plan is to try and bottle everything so hopefully even that won't be needed unless you want to install in a weird location. Sounds like a great idea though.

Teo Ljungberg

@kennethreitz I like the sound of that!
Anyone up for the challange? My python- or other programming-skills doesn't suffice, unfortunatly

Kenneth Reitz

@mxcl xcode-select is supplied.

Teo Ljungberg

@mxcl

> xcrun -find xcode-select
/usr/bin/xcode-select
Trevor Wennblom

@kennethreitz

going through the install with Xcode 4.3:

  • installed, started Xcode
  • removed stale with /Library/Developer/Shared/uninstall-devtools --mode=unixdev
  • restarted Xcode, got "To install Command Line Tools you need to log in using your Apple Developer ID." which may be worth mentioning (best to remove the Apple Dev ID requirement)

more in a bit

Kenneth Reitz

@trevor I'm pretty sure that's a legal requirement, but I'll ask.

Trevor Wennblom

@kennethreitz will it still be necessary when the components are available without ID at opensource.apple.com ?

Kenneth Reitz

@trevor I believe they will need ID still, and it will only be a link to the auth'd page — but I'll confirm.

Trevor Wennblom

for quickref, here's what happened in /usr for the steps:

/Library/Developer/Shared/uninstall-devtools --mode=unixdev
install Xcode 4.3 Command Line Tools

https://gist.github.com/1847738

(recorded with tree, so +/- isn't exact due to formatting, but you can see what's been removed and added)

Sorin Ionescu

@metamorfos, if I remember correctly, /Library/Developer/Shared/uninstall-devtools --mode=all fails to uninstall xcrun. If your xcrun shows old paths, that may be why.

Samuel John

@kennethreitz well, the developer ID is bad about that. I would not mind to kick the proprietary headers out if we can get a really free download. Not all people who use homebrew are devs or have any deeper knowledge of a compiler.

I'd love to see these tools at opensource.apple.com!

Kenneth Reitz

Those headers are crucial. OSX-GCC-Installer is what you want. I'll may be making an OSX-Clang-Installer if you really need it.

Teo Ljungberg

@sorin-ionescu I kept the Xcode suite, it can come in handy some day.

@kennethreitz I hope you inform us about the progress, perhaps make a roadmap for it?

Sorin Ionescu

@samueljohn Non-developers probably want formulae that fail to compile without the headers such as MPlayer.

Sorin Ionescu

@metamorfos Do a clean uninstall. You can also get the self-cotained Xcode.app from the Mac App Store should you need it.

Max Howell
Owner

LOL at caring that you need an Apple ID to download stuff provided at apple.com. Please do not troll this thread with more of that crap.

Anyway, also are people serious about making clang the default? My first test after doing that is brew install sl it fails! My "simplest possible formula" test fails with clang.

sl.c:62:1: error: 'main' must return 'int'

Admittedly main returning int has been the standard for god knows how long. But clang is clearly not flexible enough for open source. Thoughts?

Teo Ljungberg

@sorin-ionescu
looks like I already have and installed the Xcode.app from MAC, without me remembering it. Well, you gotta love/hate those late night coding-sessions

@kennethreitz are you in contact with apple or how did this whole thing start? I presume with the OSX-GCC package

Kenneth Reitz

@metamorfos they reached out to me when they found out about OSX-GCC-Installer. I'm working up a blog post now w/ info. I'll post here in a few.

Teo Ljungberg

@mxcl, are there any specific packages/forumulas that demand clang?

Charlie Sharpsteen
Owner

Admittedly main returning int has been the standard for god knows how long. But clang is clearly not flexible enough for open source. Thoughts?

I'll bet there is a Clang switch that can make it accept a main that doesn't return int. I think we should seriously consider defaulting to Clang moving forward. LLVM-GCC is no longer under active development which means there are a bunch of bugs and incorrect optimizations, which cause runtime errors, that will never be fixed.

Max Howell
Owner

@sharpie sounds like it's what we should do. I'm a little worried about how much breakage we might get in long tail stuff like SL though.

Max Howell
Owner

Pretty much anything that is not well maintained may not build and cause trouble. I'm one commit away from causing us all sorts of woe.

Mike McQuaid
Owner

@mxcl Clang is the default in Xcode 4.3. It works for the packages I listed above and pretty much all the C++ I throw at it at work. It's definitely flexible enough, there's just a minor monoculture of packages that only work with GCC.

Max Howell
Owner

OK, I'll push this change, but if @adamv gets mad, it's not my fault!

We can do a fails_with_clang on the other stuff.

Samuel John

@sorin-ionescu I see. Good point.

So to wrap up as I understand it, these are the different scenarios now:

  • uninstall-devtools and then install Xcode 4.3 and use xcrun (if xcode-select knows the right location of Xcode) to find out about the compiler locations.
  • Install Xcode 4.3 and have old compilers in /usr/bin that have not been uninstalled and cause trouble?
  • Install Xcode 4.3 with the additional command line tools and it just works as before by overwriting the tools in /usr/bin
  • Install just the stand-alone "command line tools for Xcode" and it should work, too.

But why do we need no Developer ID for Xcode but a Developer ID for the command line tools?

Mike McQuaid
Owner

@mxcl What change? I don't think any changes are needed unless you want to enable it for < 4.3 (which is a bad idea because the Clang is old[er] and broke).

camillol
Konstantin Shabanov

Admittedly main returning int has been the standard for god knows how long. But clang is clearly not flexible enough for open source. Thoughts?

@mxcl, drop or patch poorly maintained stuff, for example.

Just for the information - it was fixed 2 days ago: spurious/clang-mirror@5d2975d

Charlie Sharpsteen
Owner

sounds like it's what we should do. I'm a little worried about how much breakage we might get in long tail stuff like SL though.

I'm pretty sure that the set of formulae that are broken under LLVM-GCC is about the same size as the set of formulae that are broken under Clang.

One thing that we can count on is that the set of formulae broken under Clang will decrease a lot faster as the compiler is under active development. For everything else, people can always fall back to the apple-gcc formula in Homebrew-alt which provides vanilla GCC 4.2.1 built from Apple's sources.

Max Howell
Owner

@mikemcquaid the change makes clang the default for systems with vanilla Xcode 4.3, admitedly it was default for other combinations, already.

@kennethreitz may be worth pointing out to them that after I upgraded from Xcode 4.2 to 4.3 xcode-select -print-path still printed /Developer which is wrong. Also xcrun foo (if foo doesn't exist) tries to run xcodebuild. Which seems a bug.

Jack Nagel
Owner

FWIW, as a 10.6/4.2 user I've had my cc symlink pointed at clang for a few months. I have to use --use-llvm every once in a while (and some things like glib compile with clang but cause issues when things link with them) but for the most part it works.

Jack Nagel
Owner

Clang should be the default, but the fails_with_llvm stuff should be revamped to allow a formula to specify which compilers do not work and why (and for now untested formulas could be set to "fails with clang" with a special "untested" reason).

I have a working implementation of this, though the ruleset that determines when to switch to which compiler is just a placeholder. I'll push it up to my repo later today.

Max Howell
Owner

I just tried building wget with llvm and clang, saving 9 seconds (from 80) with clang. I think that's good enough reason to switch :)

Mike McQuaid
Owner

It's so fast. It also has vastly nicer error messages.

Samuel John

+1 for clang. Successfully compiled numpy and scipy with it while llvm-gcc lead to segfaults during testing.

Oh, and @mxcl correct me if I'm wrong but loading Xcode requires just an Apple ID and I'm fine with that. Loading the command line tools requires a "Developer ID". At least for now. Basically, that was my concern.

Jack Nagel
Owner

Anecdotally, I remember reading on hackernews recently that clang was used to compile the entire FreeBSD 9.0 kernel and userland. So there's definitely impetus for third party developers to start targeting clang.

Charlie Sharpsteen
Owner

It also has vastly nicer error messages.

Amen to that. Every time GCC hits a C++ template error it squats down and dumps 42 pages of gibberish to my screen that looks like the dark rites to awaken Cthulhu.

Clang gives concise accurate error messages that pinpoint the problem. And the're color coded.

Shawn Jonnet

What should we do about packages that compile with -C ?

Max Howell
Owner

I pushed the various changes related to what I was talking about.

Shawn Jonnet

I ran a brew update and then tried to install redis again. I got a new Error message?

~ > brew install redis
Error: No such file or directory - /Users/shawn/Error:

Max Howell
Owner

@sjonnet19 new ticket please. Also include all the output if that isn't it all.

Birger J. Nordølum

I removed the Xcode.app from App Store and went ahead to install the cli collection only. But now I'm a but unsure about xcode-select and xcrun.

What is the correct way to deal with these. Or do I just keep them alone if things do work?

Now I have set xcode-select to /usr but the problems is that is prepends another /usr making the path /usr/usr/bin

Sorin Ionescu

@MindTooth xcode-select --switch /

Birger J. Nordølum

I have tried that. Is it then normal for xcrun clang to take ages? Thanks.

Sorin Ionescu

Do not use xcrun.

Birger J. Nordølum

OK. Thanks again :)

Ed1t: The problem I'm having is that brew install stalls since xcrun take ages. I suspect at least. Will try a reboot.

Luc Heinrich

@sorin-ionescu Why would you point xcode-select to the root folder with xcode-select --switch /?!? I'm pretty sure this is the reason why it runs so slow for @MindTooth. Doing xcode-select --switch /Applications/Xcode.app/Contents/Developer should make it much faster.

Teo Ljungberg

@lucsky he installed the CLI tools and removed the MAC Xcode.app, then why on earth would he select /Applications/Xcode.app/...?
I think he should run xcode-select --switch /Developer/ instead

Luc Heinrich

@metamorfos Damn, sorry for not paying attention...

Shawn Jonnet

The CLT don't install to /Developer.

Teo Ljungberg

@sjonnet19 then where does it install to?

Shawn Jonnet

Standard unix directories i.e gcc -> /usr/bin/gcc

Max Howell
Owner

It seems if you install the CLI tools you get a /Developer again, so logic dictates:

sudo xcode-select -switch /Developer

After this xcrun will be fast presumably and as a bonus, it'll work too!

Shawn Jonnet

I did and it does not exist.

Mike McQuaid
Owner

Same.

Max Howell
Owner

Some people seem to have /Developer, so how confusing.

Sorin Ionescu

The people who have /Developer most likely have not uninstalled the last Xcode. Also, the Xcode uninstaller is not perfect; it leaves cruft behind. Meaning, they have to manually delete /Developer and stuff in /Library. They might also have to uninstall the old xcrun.

Type pkgutil --pkgs. See if the uninstaller missed Xcode-related packages.

The command line tools have never installed into /Developer but in /usr. There was a duplicate /Developer/usr, which no longer exists under Xcode 4.3. So, xcode-select should point to /, not /Developer.

Teo Ljungberg

I also have /Developer/
This is easily avoided by checking if /Developer/ exists. If not, sudo xcode-select --switch /usr/bin/

It's still strange that it doesn't install to /Developer in all cases

Max Howell
Owner

I think the code I wrote and subsequent patches can handle any circumstances. I even added code to find Xcode.app using Spotlight in case xcode-select is wrong and Xcode.app is not in the default location.

Shawn Jonnet

So can anyone tell me on a brand new install of lion what I need to do to get brew running. Here are the steps I have

  • Install CLI Tools
  • Install Brew

Do I need to run xcode-select as well?

Teo Ljungberg

@sorin-ionescu then why does my Xcode 4.3 have /Developer/usr/?

Max Howell
Owner

@sjonnet19 You shouldn't have to run xcode-select.

Shawn Jonnet

awesome thanks

Konstantin Shabanov etehtsea referenced this issue from a commit in etehtsea/homebrew February 16, 2012
Max Howell Find the dev tools, even with Xcode 4.3
Fixes #9179.

Conflicts:

	Library/Homebrew/extend/ENV.rb
	Library/Homebrew/utils.rb
54e4cac
Sorin Ionescu

@metamorfos Have not you told me yesterday that you have not executed a full uninstall because you wanted to keep Xcode around in case you need it, and I have said that you should delete it and install the self contained Xcode.app 4.3 when you need it? You have old Xcode 4.2 stuff in /Developer.

I have inspected Command Line Tools.mpkg. It does not put anything in /Developer.

2bits

I would agree that there's no /Developer created by the CLT or by XCode-4.3.
Personally I am lamenting the absence of aclocal. Do we need a formula for automake to get that back again?
I was able to install autoconf.rb from homebrew-alt, so at least I have autoreconf.
I guess it's just aclocal, automake, and glibtoolize that we don't have?

Jack Nagel
Owner

Eventually we'll need keg-only formulae for (at least some) of the autotools. I'm hesitant to just straight copy the homebrew-alt formula, though; they need to be audited to make sure they're up to spec for the main repo.

Charlie Sharpsteen
Owner

Although, to be honest whenever Homebrew has to run autotools there is a buildsystem bug that needs to be fixed upstream.

Charlie Sharpsteen
Owner

Or, we are doing a HEAD build and configure needs to be generated. This is the only "not an upstream bug" use for autotools that I can think of.

Jack Nagel
Owner

Yeah, can't argue with that.

Sorin Ionescu

CLT also neither installs xcode-select nor xcrun. The Xcode 4.2 uninstall fails to uninstall xcrun. You can uninstall it yourself manually.

DeveloperToolsCLI.pkg still installs the man page for xcrun, but the binary has been yanked. However, there is an xcrun in /Applications/Xcode.app/Contents/Developer/usr/bin/xcrun along with its man page.

I cannot find an xcode-select anywhere.

Kenneth Reitz

It does install xcrun and xcode-select.

Charlie Sharpsteen
Owner

CLT also neither installs xcode-select nor xcrun. The Xcode 4.2 uninstall fails to uninstall xcrun. You can uninstall it yourself manually.

These tools are included by the CLT package. Use a utility like suspicious package or Pacifist to get the scoop on what gets installed where and which scripts get run during the installation.

Sorin Ionescu

@kennethreitz They are not in the file list nor can I find them generated by scripts. Extract Command Line Tools.mpkg with Pacifist and execute find . \( -iname '*xcode-select*' -o -iname '*xcrun*' \). You will only find ./DeveloperToolsCLI Folder/usr/share/man/man1/xcrun.1. They used to be in DeveloperToolsCLI.pkg in Xcode 4.2 but they are there no longer.

2bits

20 formula call autoreconf, 36 call autogen.sh, another 15 or so call bootstrap of some sort. We might need the D8....

Charlie Sharpsteen
Owner

@sorin-ionescu

Hrm, you may be right about xcrun. This is present on my pre-upgrade, pre-xcode install VM snapshot. Going forward, the only things I have done is to apply the 10.7.3 update and install the CLT---so xcode-select has to be coming from one of those two operations.

Sorin Ionescu

@Sharpie, yes people are seeing ghosts of past installs. Hence why I advocate the presence of a good uninstaller. I intend to update and maintain gcc-without-xcode until Apple write an uninstaller for CLT.

2bits

Does xcodebuild come in the CLT? Another 20 formula call that or MacOS.xcode_*

Charlie Sharpsteen
Owner

@sorin-ionescu

My point is that on my VM, xcode-select cannot be the ghost of a past install. The history of that virtual machine looks like this:

  • Clean install from 10.7.0 App Store download (xcrun is present at this point)
  • Update to 10.7.3 via Software Update (xcode-select and xcodebuild are present at this point)
  • Install contents of command_line_tools_for_xcode.dmg
Charlie Sharpsteen
Owner

No. xcodebuild is misssing!

Arrgh. Ignore that. I had the VM booted into the wrong snapshot. xcodebuild is there.

Charlie Sharpsteen
Owner

It appears that xcode-select and xcodebuild came down in the 10.7.3 combined update that I installed through Software Update. Odd.

Birger J. Nordølum

Maybe the 10.7.3 update knew something were about to change and changed accordingly :P

Teo Ljungberg

@sorin-ionescu yeah I did, sorry for being unclear today. Work has been overwhelming.
So CLT installs to /usr/local, neat, one less PATH to be added.

So people, any ideas on what to include or exclude in our little installer? We should definatly make one to prevent confusion in the community and just all run the same setup command, i.e brew install dev-tools
Ideas?

Sorin Ionescu

@Sharpie My mistake. There used to be a com.apple.pkg.xcrun package installed by Xcode on Leopard. xcrun comes with Lion in com.apple.pkg.BSD and the 10.7.3 update. pkgutil --file-info /path/to/file prints the package name.

Max Howell
Owner

Interesting, xcrun comes with Lion (with update)? Then I can make my code that tries hard to find it less specific. Anyway I'm doing a clean install so I can make this code tight. It's important that it just works.

Birger J. Nordølum

Does even a xcode-select path get set when you start fresh and don't install the Xcode package?

Sorin Ionescu

@MindTooth At least one person has complained that xcode-select still points to /Developer.

Pete Yandell

I upgraded by installing XCode 4.3, asking it to uninstall the old tools, and then installing the command line tools package from within XCode. I found the following:

  • I now have no /Developer directory; XCode 4.3 removed it.
  • My xcode-select path was still set to /Developer.
  • "sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer" sorted things out

Things that I tried that are broken:

  • "sudo xcode-select -switch /" or "sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer/" (note the trailing slash) both caused xcrun to lock up for extended periods of time. No idea why.
  • The Redis build only works with --use-gcc. (Is there a way to tell a formula to default to gcc?)
Charlie Sharpsteen
Owner

Is there a way to tell a formula to default to gcc?

When using Xcode 4.2 or newer, there is no GCC installed to default to. There is an apple-gcc formula in Homebrew-alt that will install the old compiler---but this is just a stopgap measure. Best would be to try compiling Redis under --use-clang and if it fails, submit a bug to Redis so they can get it fixed.

Otherwise, we'll be stuck supporting a compiler released in 2007 forever.

Max Howell
Owner

Just fresh installed Lion. And then upgraded to 10.7.3.

I have xcrun, xcode-select and xcodebuild installed.

Stupidly didn't check before updating to 10.7.3, but I don't think it matters too much.

Will now install Xcode 4.3.

Jack Nagel
Owner

The Redis build only works with --use-gcc.

Redis builds with LLVM, but not clang.

2bits

@mxcl what is your xcode-select -print-path and does your xcodebuild -version hang?
fwiw, Mercurial is now broken, as it calls a python script that runs /usr/bin/xcodebuild -version
and I can't craft an xcode -switch that lets that command succeed.

$ sudo xcode-select -switch /usr/bin
$ xcodebuild -version
error: can't exec '/usr/bin/usr/bin/xcodebuild' (No such file or directory)

and sudo xcode-select -switch / makes xcodebuild hang.

Sorin Ionescu

@2bits xcode-select -switch /

Max Howell
Owner

Just to add additional information here. Installing Xcode 4.3, then the CLI tools from within Xcode Preferences, gave me a /usr/bin/cc. Previously when upgrading from Xcode 4.2 this symlink stopped existing.

2bits

@sorin-ionescu that command causes xcodebuild to hang indefinitely.

sudo xcode-select -switch /
xcodebuild -version

hangs with zero disk activity, zero network activity, and xcodebuild using 72% cpu.
I guess you have success with it, though.

Max Howell
Owner

Homebrew doesn't need xcodebuild -version or xcode-select to work, it hasn't for a while. And I made sure the last couple days that all paths that could use it can cope without. So I wouldn't worry about it.

The problem remains of course that some build scripts depend on the xcode version. They probably shouldn't and never should have. Chances are they are querying for compiler versions this way. I know we have!

2bits

brew doctor is broken because it calls xcodebuild -version which hangs ... I am lost.

utils.rb:347:      `xcodebuild -version 2>&1` =~ /Xcode (\d(\.\d)*)/

I guess it's my fault that I had run sudo xcode-select -switch /

camillol

Completely off-topic, but is there a way to mark all notifications as read for this issue (= not "mark all as read" in the notification page) until now (= not "disable notifications for this issue" at the bottom)?

Sorin Ionescu

@mxcl, here's a good way to find commands.

def exists?(command)
  ENV['PATH'].split(':').map do |directory|
    File.exists?(File.join(directory, command))
  end.include?(true)
end

exists?('git')
exists?('cc')
camillol
Sorin Ionescu

In the past, installing Xcode used to overwrite a lot of existing files. So, it was very scary to uninstall it. CLT only overwrites Subversion and another program. So, should you ever wish to uninstall the CLT packages listed above with pkgutil --unlink, it should not destroy your system.

mkdir foo; pushd foo
for package in /Volumes/Command\ Line\ Tools/Packages/*.pkg; do
  xar -x -f "$package" Payload;
  while NFS=$'\n' read line; do
    query="${line#\.}";
    if [[ -f "${query}" ]]; then
      echo "${query}";  fi;
    done < <(gzcat Payload | cpio -it 2>/dev/null);
    rm -rf *; # Be careful from where you run this.
  done
popd; rmdir foo

/usr/share/man/man1/compileHelp.1
/usr/bin/codesign_allocate
/usr/share/man/man1/codesign_allocate.1
/usr/bin/svn
/usr/bin/svnadmin
/usr/bin/svndumpfilter
/usr/bin/svnlook
/usr/bin/svnserve
/usr/bin/svnsync
/usr/bin/svnversion

Sorin Ionescu

@camillol, @mxcl I have forgotten about any?.

def exists?(command)
  ENV['PATH'].split(':').any? do |directory|
    File.exists?(File.join(directory, command))
  end
end

In any case, it is better than hardcoding paths to programs and having Homebrew break whenever a major Xcode version is released.

Samuel John

I uninstalled old Xcode 4.2 and then installed XCode 4.3 but not yet the CLTools. I set my xcode-select to the right path

xcode-select -print-path
/Applications/Xcode.app/Contents/Developer

brew doctor tells me:

You have no /usr/bin/cc.
This means you probably can't build *anything*. You need to install the CLI
Tools for Xcode. You can either download this from http://connect.apple.com/
or install them from inside Xcode’s preferences. Homebrew does not require
all of Xcode! You only need the CLI tools package!

homebrew revision: 4e9c4e3

xcrun -find cc works:

xcrun -find cc
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
Mike McQuaid
Owner

I'm guessing a solution to these problems are telling people what they need to set xcode-select to. It seems by default (and given old configurations) it isn't set up properly.

Felix Schulze

With a fresh lion install and Xcode 4.3 the following command works fine:

sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer
Samuel John

@x2on you mean a fresh Xcode 4.3 without the command line tools? My brew doctor tells me it cannot find /usr/bin/cc (see posting above) but my xcode-select works and xcrun cc is working, too. Perhaps you have old remains of /usr/bin/cc?

Felix Schulze

@samueljohn I installed a complete fresh copy of lion, installed Xcode 4.3 and the command line tools from Xcode settings panel. Than i used the xcode-select command above and then i installed homebrew and have no problems.

Samuel John

@x2on That is true. So the reason it works are the command line tools.

However, I just tested with the mac of my girlfriend. She has 10.7.3 and never had Xcode installed. Now I installed Xcode 4.3 (without command line tools for Xcode) and the xcode-select path is not set. I repeat not.
And brew doctor complains "You have no /usr/bin/cc".

Then I set sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer. But still I get the same result from brew doctor: "You have no /usr/bin/cc".

Testing xcrun -find cc works fine. Thus I believe homebrew's could still improve.
Of course we could just say: Xcode does not matter, always install the command line tools.

Sorin Ionescu

Stuff inside Xcode.app is meant for Xcode.app. Install CLT and xcode-select -switch /; though, brew works without it.

2bits

Am I the only one who can't brew doctor after setting that switch to /? I can not figure how @sorin-ionescu does it.

Birger J. Nordølum

Problem applies to my setup as well. Stalls forever.

Sorin Ionescu

I have a clean system. I have used my own gcc-without-xcode to cleanly install and uninstall the Xcode 4.2 command line tools. Once I removed them, I upgraded to Mac OS X 10.7.3 then installed CLT from command_line_tools_for_xcode.dmg.

I have pulled the latest Homebrew. Whence before, for Xcode 4.2, I had to set the xcode-select path, now Homebrew works without it set. If I execute xcode-select -print-path, I get the error bellow.

xcode-select: Error: No Xcode folder is set. Run xcode-select -switch to set the path to the Xcode folder.

brew doctor does not freeze. It outputs the following text, which I care not fix since it does provide detailed information of why I should do so, especially the Git part.

You can install Homebrew anywhere you want, but some brews may only build
correctly if you install to /usr/local.

Some brews install binaries to sbin instead of bin, but Homebrew's
sbin was not found in your path.

Consider editing your .bashrc to add:
/Users/sorin/.tilde/opt/sbin
to the PATH variable.

Suspicious Git newline settings found.

The detected Git newline settings can cause checkout problems:
core.autocrlf = input
core.safecrlf = true

If you are not routinely dealing with Windows-based projects,
consider removing these settings.

2bits

Ok so you are telling people to set the switch to /, but you run with the switch unset? I must have missed something, sorry.

Sorin Ionescu

@2bits If you have a dirty system, the path is set to /Developer, and anything that uses xcode-select will look for /Developer/usr/bin/clang, which no longer exists. So, it has to be set to / to find /usr/bin/clang installed by CLT.

The path is set in /usr/share/xcode-select/xcode_dir_path. You can delete the file, if you wish.

2bits

Thanks I was just running a find -newer to see where that darn thing is stored :-)
I would disagree that it should to be set to / if the user is going to issue the brew command, because that confuses Homebrew which depends on it not hanging xcodebuild -version per line 347 of utils.rb, but I'll stop beating that horse lol.

Sorin Ionescu

@2bits Up until now, I have used it set to / for years. If the tools are in usr/bin, and usr/bin is in /, to what do you want it set? Just install a clean version of OS X 10.7.0, upgrade to 10.7.3, and install CLT and be done with this.

Felix Schulze

Another trick for old build scripts is:

sudo ln -s /Applications/Xcode.app/Contents/Developer /Developer
Martin mtandersson referenced this issue from a commit February 19, 2012
Commit has since been removed from the repository and is no longer available.
Charlie Sharpsteen Sharpie referenced this issue from a commit February 19, 2012
Commit has since been removed from the repository and is no longer available.
Ethan Schoonover

It's not clear to me based on this thread if there is a consistent experience for new installs, but on a fresh 10.7.3 OS X install, new xcode/CLT install only:

sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer

worked, while setting the xcode path to root does not work here.

  • n.b. that with xcode path to root, brew doctor and most other operations hang.
  • without the path set at all (removed /usr/share/xcode-select/xcode_dir_path), brew finds /usr/bin/clang during the build fine but still fails due to xcode-select
Crazor

Note: according to xcode-select's manpage, you should run sudo xcode-select -switch /Applications/Xcode.app. I tried this on 10.8/Xcode 4.4 and 10.7/Xcode 4.3, and it worked as described.
Maybe appending /Contents/Developer is currently working, too, but since that is not the official way, it might break in an update and confuse users reading this.

Sorin Ionescu

@Crazor So, in 4.3, if you want to use CLT, don't set a path, and if you want to use Xcode, set it to Xcode.app's root folder?

Crazor

I'm not entirely sure about that. I still have to try with a clean install. On my MBAir updated from Xcode 4.2 to 4.3, Homebrew didn't work without the CLT installed, even after messing around with xcode-select. Although I can confirm that setting to XCode.app's root folder allows xcrun to find its tools.

Crazor

Update: It seems that sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer should work in future Xcode versions, too. Quoting the manpage:

-switch xcode_path
Sets the path to the current Xcode, e.g. "/Xcode4.2". This command must be run with superuser permissions, and will affect all users on the system. To set the path without
superuser permissions or only for the current shell session, use the DEVELOPER_DIR environment variable instead.

As a convenience, for Xcode 4.3 and later, you can supply just the path to the Xcode application, e.g. "/Applications/Xcode.app", and xcode-select will determine the proper path to the Developer directory it contains.

Max Howell
Owner

A summary:

  • Setting xcode-select to / breaks all the Xcode CLI tools, so don't do that.
  • You have to install CLT4Xcode to compile stuff with Homebrew

Possibly the second can be fixed. However it is not as trivial as just making sure Homebrew knows where to find cc et al. The build tools also need to know where to find the important headers and libraries in the Xcode.app folder. And we're not 100% sure that all of them are actually provided without the CLT4Xcode anyway.

brew doctor hanging can be fixed, though ideally the Xcode team will make it not hang if you set xcode-select to / since it seems that should be the valid setting if you only install the CLT.

Charlie Sharpsteen
Owner

Settingxcode-select to / breaks all the Xcode CLI tools, so don't do that.

Note that not setting a path for xcode-select results in xcodebuild being broken as well. As we have a few formulae that use xcodebuild, we need to find a solution for users that only install the CLT that results in a functional xcodebuild.

Sorin Ionescu

@Sharpie I presume that xcodebuild requires Xcode.app in order to build Xcode projects, does it not?

Charlie Sharpsteen
Owner

I presume that xcodebuild requires Xcode.app in order to build Xcode projects, does it not?

I always thought it was the other way around---Xcode.app drops a system call to xcodebuild to compile projects and xcodebuild serves a function similar to make.

John Harrison

@Sharpie xcodebuild (the one in the Developer/usr/bin directory, not /usr/bin/xcodebuild) is an executable that does some magic, like read in Xcode project settings before calling compilers/linkers/etc. If you do not install Xcode.app, then you won't have access to the xcodebuild executable.

/usr/bin/xcodebuild is a shell script that finds the current version of the xcodebuild executable. So, while it does serve a similar purpose as make, it will not work with just the CLT installed, they are going to have to install Xcode.app for those formulae to build.

You could bottle anything that requires xcodebuild to build as an alternative, maybe?

Charlie Sharpsteen
Owner

@ashgti

Makes sense. Thanks for the clarification.

@kennethreitz

Next time you speak to Apple, could you suggest including a working xcodebuild in the command line tools? Don't know if they can do it, but it would help projects like MacVim and Fuse4x.

Max Howell
Owner

I bet they can't do it.

There's plenty of build systems out there. MacVIM and Fuse4x can pick another if they want to play. Not fun for them of course, but software dev is full of these gotchas.

Jamie Kirkpatrick

FYI - I've submitted a pull-request to fix up the problems with CMake

Andreas Möller

I've read this thread but still have no autoconf, which I need. How can I achieve this?

Mike McQuaid
Owner

brew install https://raw.github.com/adamv/homebrew-alt/master/duplicates/autoconf.rb

Max Howell
Owner

I'm just going to move autoconf from alt to master if nobody has objections.

Mike McQuaid
Owner

Can you make it barf on non-Xcode 4.3?

2bits

autoconf deps on m4. Lion uses an old m4-1.4.6, rather than 1.4.16. Autoconf complains. Can we build m4 with threads and c++ if we use the newer one?. Built like that, m4 passes make check on Lion. Autoconf-2.68 doesn't but I've not nailed down whether the fails are significant, though I've tried on bug-autoconf mailing list. w/e works is good.

Sorin Ionescu

@2bits m4 will have to be a keg.

2bits

sounds good. it has an odd dep on libsigsegv. not sure why.

Adam Vandenberg adamv reopened this February 26, 2012
Adam Vandenberg
Owner

Reopening since discussion is still going on here...

Max Howell mxcl referenced this issue from a commit February 27, 2012
Max Howell Autoconf, Automake and Libtool
We need these now for Xcode-4.3/CLT4X installations.

Also prevent m4 error in installer. And prevent brew doctor complaining if we're Xcode 4.3 or above.

Closes #10349. Fixes #10423. Refs #9179.
b0c81fc
royhodgman royhodgman referenced this issue from a commit February 27, 2012
Commit has since been removed from the repository and is no longer available.
camillol

@mxcl so the current autotools require GNU libtool?

BTW, the current libtool seems to be 2.4.2, not 2.4.

Max Howell
Owner

Apple don't provide libtoolize. If I somehow didn't provide the most current libtool, patches are welcome. Thanks.

Anatol

@mxcl Does it mean that using xcodebuild for project (such as fuse4x) is discouraged? If so what is the best build system alternative for these projects?

fuse4x-kext uses xcodebuild because it provides a lot of plumbing for KEXT building, e.g. creates kext directory structure, sets required compile/link flags. Are there any good examples of KEXT projects that do not use xcodebuild?

Charlie Sharpsteen Sharpie referenced this issue from a commit February 29, 2012
Commit has since been removed from the repository and is no longer available.
camillol

@anatol if you need xcodebuild, use xcodebuild. Won't most users install the binary packages for fuse4x anyway?

2bits 2bits referenced this issue from a commit in 2bits/homebrew February 29, 2012
2bits libtool 2.4.2
Upgrade libtool to version 2.4.2 per mxcl req in #9179
56311b3
Max Howell
Owner
mxcl commented March 01, 2012

@anatol using xcodebuild should be fine. It's just that by default the CLI tools don't work with it. I'll talk with the Xcode guys and figure out if they are going to fix that. Maybe xcodebuild can only be used if you have Xcode installed.

For now we may have to error out with a better error message.

Max Howell
Owner
mxcl commented March 01, 2012

I believe everything we can do is fixed.

Max Howell mxcl closed this March 01, 2012
John Firebaugh

@mxcl Now that Xcode 4.3 CLT no longer includes gcc, would you consider including the apple-gcc42 formula from homebrew-alt? It's needed to compile Ruby 1.8.7 (in fact, any Ruby version < 1.9.3-p125).

Max Howell
Owner
mxcl commented March 01, 2012

@jfirebaugh I believe there's a ticket for this already. So yes.

Jack Nagel jacknagel referenced this issue from a commit February 29, 2012
2bits libtool 2.4.2
Upgrade libtool to version 2.4.2 per mxcl req in #9179

Closes #10610.

Signed-off-by: Jack Nagel <jacknagel@gmail.com>
380632f
Konstantin Shabanov etehtsea referenced this issue from a commit in etehtsea/homebrew February 27, 2012
Max Howell Autoconf, Automake and Libtool
We need these now for Xcode-4.3/CLT4X installations.

Also prevent m4 error in installer. And prevent brew doctor complaining if we're Xcode 4.3 or above.

Closes #10349. Fixes #10423. Refs #9179.
636fb68
Brian Sniffen briansniffen referenced this issue from a commit in briansniffen/homebrew February 29, 2012
2bits libtool 2.4.2
Upgrade libtool to version 2.4.2 per mxcl req in #9179

Closes #10610.

Signed-off-by: Jack Nagel <jacknagel@gmail.com>
4d29ad6
Maria Neise MNeise referenced this issue from a commit February 27, 2012
Max Howell Autoconf, Automake and Libtool
We need these now for Xcode-4.3/CLT4X installations.

Also prevent m4 error in installer. And prevent brew doctor complaining if we're Xcode 4.3 or above.

Closes #10349. Fixes #10423. Refs #9179.
9e5c7e3
Maria Neise MNeise referenced this issue from a commit February 29, 2012
2bits libtool 2.4.2
Upgrade libtool to version 2.4.2 per mxcl req in #9179

Closes #10610.

Signed-off-by: Jack Nagel <jacknagel@gmail.com>
88d6e88
Christopher Coco cacoco referenced this issue from a commit February 27, 2012
Max Howell Autoconf, Automake and Libtool
We need these now for Xcode-4.3/CLT4X installations.

Also prevent m4 error in installer. And prevent brew doctor complaining if we're Xcode 4.3 or above.

Closes #10349. Fixes #10423. Refs #9179.
c876e3a
Christopher Coco cacoco referenced this issue from a commit February 29, 2012
2bits libtool 2.4.2
Upgrade libtool to version 2.4.2 per mxcl req in #9179

Closes #10610.

Signed-off-by: Jack Nagel <jacknagel@gmail.com>
889ad8c
Charlie Sharpsteen Sharpie referenced this issue from a commit in Sharpie/homebrew February 16, 2012
Max Howell Find the dev tools, even with Xcode 4.3
Fixes #9179.
160004e
Charlie Sharpsteen Sharpie referenced this issue from a commit in Sharpie/homebrew February 27, 2012
Max Howell Autoconf, Automake and Libtool
We need these now for Xcode-4.3/CLT4X installations.

Also prevent m4 error in installer. And prevent brew doctor complaining if we're Xcode 4.3 or above.

Closes #10349. Fixes #10423. Refs #9179.
fe4665f
Charlie Sharpsteen Sharpie referenced this issue from a commit in Sharpie/homebrew February 27, 2012
Max Howell Autoconf, Automake and Libtool
We need these now for Xcode-4.3/CLT4X installations.

Also prevent m4 error in installer. And prevent brew doctor complaining if we're Xcode 4.3 or above.

Closes #10349. Fixes #10423. Refs #9179.
3c2488d
Charlie Sharpsteen Sharpie referenced this issue from a commit in Sharpie/homebrew February 29, 2012
2bits libtool 2.4.2
Upgrade libtool to version 2.4.2 per mxcl req in #9179

Closes #10610.

Signed-off-by: Jack Nagel <jacknagel@gmail.com>
64b366c
snakeyroc3 snakeyroc3 referenced this issue from a commit in snakeyroc3/homebrew February 16, 2012
Max Howell Find the dev tools, even with Xcode 4.3
Fixes #9179.
968274d
snakeyroc3 snakeyroc3 referenced this issue from a commit in snakeyroc3/homebrew February 27, 2012
Max Howell Autoconf, Automake and Libtool
We need these now for Xcode-4.3/CLT4X installations.

Also prevent m4 error in installer. And prevent brew doctor complaining if we're Xcode 4.3 or above.

Closes #10349. Fixes #10423. Refs #9179.
941e0cf
snakeyroc3 snakeyroc3 referenced this issue from a commit in snakeyroc3/homebrew February 29, 2012
2bits libtool 2.4.2
Upgrade libtool to version 2.4.2 per mxcl req in #9179

Closes #10610.

Signed-off-by: Jack Nagel <jacknagel@gmail.com>
3196b8a
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.