Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Support for Xcode 4.3 #9179

Closed
xose opened this Issue · 225 comments
@xose

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?

@Sharpie
Collaborator

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.

@xose

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.

@jacknagel
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.

@adamv
Owner

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

@ashgti

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.

@Sharpie
Collaborator

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.

@jacknagel
Owner

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

@xose

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

@mikemcquaid
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.

@ashgti

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

@ashgti

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.

@xose

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.
@jacknagel
Owner

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

That's really disappointing.

@jacknagel
Owner

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

@xose

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.

@mikemcquaid
Owner

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

@samueljohn
  • 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?

@xose

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?

@etehtsea

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.

@samueljohn

@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
@jacknagel
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.

@mikemcquaid
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.

@mikemcquaid
Owner

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

@jacknagel
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).

@mikemcquaid
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.

@mikemcquaid
Owner

And for autotools just make them keg-only.

@mikemcquaid
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.

@jacknagel
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.

@mxcl
Collaborator

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.

@mxcl
Collaborator

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!

@mikemcquaid
Owner

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

@mikemcquaid
Owner

And cheers @mxcl.

@mxcl
Collaborator

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.

@chadcatlett

@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?

@chadcatlett

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

@jacknagel
Owner

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

@mxcl
Collaborator

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

@mxcl mxcl closed this in 2fab16e
@mxcl
Collaborator

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.

@mikemcquaid
Owner

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

@jacknagel
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.

@mikemcquaid
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.

@jacknagel
Owner

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

@jacknagel
Owner

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

@kennethreitz

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.

@kennethreitz

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

@mxcl
Collaborator

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?

@etehtsea

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

@kennethreitz

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.

@etehtsea

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.

@kennethreitz

That won't be a problem.

@mikemcquaid
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).

@etehtsea

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

Highly support this idea.

@mikemcquaid
Owner

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

@mxcl
Collaborator

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.

@mxcl
Collaborator

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.

@etehtsea

Does anywhere exist a list of clang incompatible things?

@teoljungberg

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?

@mxcl
Collaborator

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.

@mikemcquaid
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.

@kennethreitz

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.

@mikemcquaid
Owner

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

@teoljungberg

@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

@mikemcquaid
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/.

@mikemcquaid
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.

@mikemcquaid
Owner

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

@teoljungberg

@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

@kennethreitz

@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.

@mikemcquaid
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.

@teoljungberg

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

@kennethreitz

@mxcl xcode-select is supplied.

@teoljungberg

@mxcl

> xcrun -find xcode-select
/usr/bin/xcode-select
@trevor

@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

@kennethreitz

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

@trevor

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

@kennethreitz

@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

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.

@samueljohn

@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!

@kennethreitz

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.

@teoljungberg

@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.

@mxcl
Collaborator

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?

@teoljungberg

@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

@kennethreitz

@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.

@teoljungberg

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

@Sharpie
Collaborator

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.

@mxcl
Collaborator

@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.

@mxcl
Collaborator

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.

@mikemcquaid
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.

@mxcl
Collaborator

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.

@samueljohn

@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?

@mikemcquaid
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
@etehtsea

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

@Sharpie
Collaborator

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.

@mxcl
Collaborator

@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.

@jacknagel
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.

@jacknagel
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.

@mxcl
Collaborator

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 :)

@mikemcquaid
Owner

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

@samueljohn

+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.

@jacknagel
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.

@Sharpie
Collaborator

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.

@sjonnet19

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

@mxcl
Collaborator

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

@sjonnet19

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:

@mxcl
Collaborator

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

@MindTooth

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 /

@MindTooth

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

@sorin-ionescu

Do not use xcrun.

@MindTooth

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.

@lucsky

@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.

@teoljungberg

@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

@lucsky

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

@sjonnet19

The CLT don't install to /Developer.

@teoljungberg

@sjonnet19 then where does it install to?

@sjonnet19

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

@mxcl
Collaborator

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!

@sjonnet19

I did and it does not exist.

@mikemcquaid
Owner

Same.

@mxcl
Collaborator

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.

@teoljungberg

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

@mxcl
Collaborator

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.

@sjonnet19

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?

@teoljungberg

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

@mxcl
Collaborator

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

@sjonnet19

awesome thanks

@etehtsea etehtsea referenced this issue from a commit in etehtsea/homebrew
@mxcl mxcl 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?

@jacknagel
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.

@Sharpie
Collaborator

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

@Sharpie
Collaborator

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.

@jacknagel
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.

@kennethreitz

It does install xcrun and xcode-select.

@Sharpie
Collaborator

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....

@Sharpie
Collaborator

@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_*

@Sharpie
Collaborator

@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
@Sharpie
Collaborator

No. xcodebuild is misssing!

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

@Sharpie
Collaborator

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

@MindTooth

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

@teoljungberg

@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.

@mxcl
Collaborator

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.

@MindTooth

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.

@notahat

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?)
@Sharpie
Collaborator

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.

@mxcl
Collaborator

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.

@jacknagel
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 /

@mxcl
Collaborator

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.

@mxcl
Collaborator

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.

@samueljohn

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
@mikemcquaid
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.

@x2on

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

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

@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?

@x2on

@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.

@samueljohn

@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.

@MindTooth

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.

@x2on

Another trick for old build scripts is:

sudo ln -s /Applications/Xcode.app/Contents/Developer /Developer
@mtandersson mtandersson referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@Sharpie Sharpie referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@altercation

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.

@mxcl
Collaborator

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.

@Sharpie
Collaborator

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?

@Sharpie
Collaborator

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.

@ashgti

@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?

@Sharpie
Collaborator

@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.

@mxcl
Collaborator

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.

@jkp

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

@localheinz

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

@mikemcquaid
Owner

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

@mxcl
Collaborator

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

@mikemcquaid
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.

@adamv adamv reopened this
@adamv
Owner

Reopening since discussion is still going on here...

@mxcl mxcl referenced this issue from a commit
@mxcl mxcl 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
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.

@mxcl
Collaborator

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?

@Sharpie Sharpie referenced this issue from a commit
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
@2bits 2bits libtool 2.4.2
Upgrade libtool to version 2.4.2 per mxcl req in #9179
56311b3
@2bits 2bits referenced this issue
Closed

libtool 2.4.2 #10610

@mxcl
Collaborator

@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.

@mxcl
Collaborator

I believe everything we can do is fixed.

@mxcl mxcl closed this
@jfirebaugh

@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).

@mxcl
Collaborator

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

@jacknagel jacknagel referenced this issue from a commit
@2bits 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
@etehtsea etehtsea referenced this issue from a commit in etehtsea/homebrew
@mxcl mxcl 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
@briansniffen briansniffen referenced this issue from a commit in briansniffen/homebrew
@2bits 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
@MNeise MNeise referenced this issue from a commit
@mxcl mxcl 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
@MNeise MNeise referenced this issue from a commit
@2bits 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
@cacoco cacoco referenced this issue from a commit
@mxcl mxcl 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
@cacoco cacoco referenced this issue from a commit
@2bits 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
@Sharpie Sharpie referenced this issue from a commit in Sharpie/homebrew
@mxcl mxcl Find the dev tools, even with Xcode 4.3
Fixes #9179.
160004e
@Sharpie Sharpie referenced this issue from a commit in Sharpie/homebrew
@mxcl mxcl 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
@Sharpie Sharpie referenced this issue from a commit in Sharpie/homebrew
@mxcl mxcl 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
@Sharpie Sharpie referenced this issue from a commit in Sharpie/homebrew
@2bits 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
@mxcl mxcl Find the dev tools, even with Xcode 4.3
Fixes #9179.
968274d
@snakeyroc3 snakeyroc3 referenced this issue from a commit in snakeyroc3/homebrew
@mxcl mxcl 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
@2bits 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.