This repository has been archived by the owner. It is now read-only.

Support for Xcode 4.3 #9179

Closed
xose opened this Issue Dec 19, 2011 · 225 comments

Comments

Projects
None yet
@xose
Contributor

xose commented Dec 19, 2011

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

This comment has been minimized.

Show comment
Hide comment
@camillol

camillol Dec 19, 2011

Contributor

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

Contributor

camillol commented Dec 19, 2011

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

@Sharpie

This comment has been minimized.

Show comment
Hide comment
@Sharpie

Sharpie Dec 19, 2011

Contributor

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.

Contributor

Sharpie commented Dec 19, 2011

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

This comment has been minimized.

Show comment
Hide comment
@xose

xose Dec 19, 2011

Contributor

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.

Contributor

xose commented Dec 19, 2011

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

This comment has been minimized.

Show comment
Hide comment
@jacknagel

jacknagel Dec 19, 2011

Contributor

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.

Contributor

jacknagel commented Dec 19, 2011

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

This comment has been minimized.

Show comment
Hide comment
@adamv

adamv Dec 19, 2011

Contributor

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

Contributor

adamv commented Dec 19, 2011

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

@ashgti

This comment has been minimized.

Show comment
Hide comment
@ashgti

ashgti Dec 19, 2011

Contributor

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.

Contributor

ashgti commented Dec 19, 2011

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

This comment has been minimized.

Show comment
Hide comment
@Sharpie

Sharpie Dec 19, 2011

Contributor

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.

Contributor

Sharpie commented Dec 19, 2011

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

This comment has been minimized.

Show comment
Hide comment
@camillol

camillol Dec 19, 2011

Contributor

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.

Contributor

camillol commented Dec 19, 2011

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

This comment has been minimized.

Show comment
Hide comment
@jacknagel

jacknagel Dec 19, 2011

Contributor

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

Contributor

jacknagel commented Dec 19, 2011

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

@xose

This comment has been minimized.

Show comment
Hide comment
@xose

xose Dec 20, 2011

Contributor

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

Contributor

xose commented Dec 20, 2011

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

This comment has been minimized.

Show comment
Hide comment
@MikeMcQuaid

MikeMcQuaid Dec 21, 2011

Member

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.

Member

MikeMcQuaid commented Dec 21, 2011

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

This comment has been minimized.

Show comment
Hide comment
@ashgti

ashgti Dec 22, 2011

Contributor

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

Contributor

ashgti commented Dec 22, 2011

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

@ashgti

This comment has been minimized.

Show comment
Hide comment
@ashgti

ashgti Dec 25, 2011

Contributor

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.

Contributor

ashgti commented Dec 25, 2011

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 comment has been minimized.

Show comment
Hide comment
@xose

xose Jan 10, 2012

Contributor

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

xose commented Jan 10, 2012

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

This comment has been minimized.

Show comment
Hide comment
@jacknagel

jacknagel Jan 10, 2012

Contributor

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

That's really disappointing.

Contributor

jacknagel commented Jan 10, 2012

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

That's really disappointing.

@jacknagel

This comment has been minimized.

Show comment
Hide comment
@jacknagel

jacknagel Jan 11, 2012

Contributor

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

Contributor

jacknagel commented Jan 11, 2012

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

@xose

This comment has been minimized.

Show comment
Hide comment
@xose

xose Jan 11, 2012

Contributor

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.

Contributor

xose commented Jan 11, 2012

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

This comment has been minimized.

Show comment
Hide comment
@MikeMcQuaid

MikeMcQuaid Feb 16, 2012

Member

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

Member

MikeMcQuaid commented Feb 16, 2012

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

@samueljohn

This comment has been minimized.

Show comment
Hide comment
@samueljohn

samueljohn Feb 16, 2012

Contributor
  • 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?

Contributor

samueljohn commented Feb 16, 2012

  • 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

This comment has been minimized.

Show comment
Hide comment
@xose

xose Feb 16, 2012

Contributor

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

Contributor

xose commented Feb 16, 2012

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

@sorin-ionescu

This comment has been minimized.

Show comment
Hide comment
@sorin-ionescu

sorin-ionescu Feb 16, 2012

Contributor

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.

Contributor

sorin-ionescu commented Feb 16, 2012

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

This comment has been minimized.

Show comment
Hide comment
@sorin-ionescu

sorin-ionescu Feb 16, 2012

Contributor

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

Contributor

sorin-ionescu commented Feb 16, 2012

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

@etehtsea

This comment has been minimized.

Show comment
Hide comment
@etehtsea

etehtsea Feb 16, 2012

Contributor

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.

Contributor

etehtsea commented Feb 16, 2012

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

This comment has been minimized.

Show comment
Hide comment
@samueljohn

samueljohn Feb 16, 2012

Contributor

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

Contributor

samueljohn commented Feb 16, 2012

@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

This comment has been minimized.

Show comment
Hide comment
@sorin-ionescu

sorin-ionescu Feb 16, 2012

Contributor

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
Contributor

sorin-ionescu commented Feb 16, 2012

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

This comment has been minimized.

Show comment
Hide comment
@jacknagel

jacknagel Feb 16, 2012

Contributor

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.

Contributor

jacknagel commented Feb 16, 2012

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

This comment has been minimized.

Show comment
Hide comment
@MikeMcQuaid

MikeMcQuaid Feb 16, 2012

Member

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.

Member

MikeMcQuaid commented Feb 16, 2012

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

This comment has been minimized.

Show comment
Hide comment
@MikeMcQuaid

MikeMcQuaid Feb 16, 2012

Member

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

Member

MikeMcQuaid commented Feb 16, 2012

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

@jacknagel

This comment has been minimized.

Show comment
Hide comment
@jacknagel

jacknagel Feb 16, 2012

Contributor

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

Contributor

jacknagel commented Feb 16, 2012

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

This comment has been minimized.

Show comment
Hide comment
@MikeMcQuaid

MikeMcQuaid Feb 16, 2012

Member

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

Member

MikeMcQuaid commented Feb 16, 2012

@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

This comment has been minimized.

Show comment
Hide comment
@MikeMcQuaid

MikeMcQuaid Feb 16, 2012

Member

And for autotools just make them keg-only.

Member

MikeMcQuaid commented Feb 16, 2012

And for autotools just make them keg-only.

@MikeMcQuaid

This comment has been minimized.

Show comment
Hide comment
@MikeMcQuaid

MikeMcQuaid Feb 16, 2012

Member

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

Member

MikeMcQuaid commented Feb 16, 2012

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

This comment has been minimized.

Show comment
Hide comment
@jacknagel

jacknagel Feb 16, 2012

Contributor

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.

Contributor

jacknagel commented Feb 16, 2012

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

This comment has been minimized.

Show comment
Hide comment
@sorin-ionescu

sorin-ionescu Feb 16, 2012

Contributor

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

Contributor

sorin-ionescu commented Feb 16, 2012

@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

This comment has been minimized.

Show comment
Hide comment
@mxcl

mxcl Feb 16, 2012

Member

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.

Member

mxcl commented Feb 16, 2012

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

This comment has been minimized.

Show comment
Hide comment
@mxcl

mxcl Feb 16, 2012

Member

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!

Member

mxcl commented Feb 16, 2012

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!

@Sharpie

This comment has been minimized.

Show comment
Hide comment
@Sharpie

Sharpie Feb 20, 2012

Contributor

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.

Contributor

Sharpie commented Feb 20, 2012

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

This comment has been minimized.

Show comment
Hide comment
@ashgti

ashgti Feb 20, 2012

Contributor

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

Contributor

ashgti commented Feb 20, 2012

@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

This comment has been minimized.

Show comment
Hide comment
@Sharpie

Sharpie Feb 20, 2012

Contributor

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

Contributor

Sharpie commented Feb 20, 2012

@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

This comment has been minimized.

Show comment
Hide comment
@mxcl

mxcl Feb 20, 2012

Member

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.

Member

mxcl commented Feb 20, 2012

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

This comment has been minimized.

Show comment
Hide comment
@jkp

jkp Feb 21, 2012

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

jkp commented Feb 21, 2012

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

@localheinz

This comment has been minimized.

Show comment
Hide comment
@localheinz

localheinz Feb 24, 2012

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

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

@MikeMcQuaid

This comment has been minimized.

Show comment
Hide comment
@MikeMcQuaid

MikeMcQuaid Feb 24, 2012

Member

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

Member

MikeMcQuaid commented Feb 24, 2012

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

@mxcl

This comment has been minimized.

Show comment
Hide comment
@mxcl

mxcl Feb 26, 2012

Member

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

Member

mxcl commented Feb 26, 2012

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

@MikeMcQuaid

This comment has been minimized.

Show comment
Hide comment
@MikeMcQuaid

MikeMcQuaid Feb 26, 2012

Member

Can you make it barf on non-Xcode 4.3?

Member

MikeMcQuaid commented Feb 26, 2012

Can you make it barf on non-Xcode 4.3?

@2bits

This comment has been minimized.

Show comment
Hide comment
@2bits

2bits Feb 26, 2012

Contributor

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.

Contributor

2bits commented Feb 26, 2012

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

This comment has been minimized.

Show comment
Hide comment
@sorin-ionescu

sorin-ionescu Feb 26, 2012

Contributor

@2bits m4 will have to be a keg.

Contributor

sorin-ionescu commented Feb 26, 2012

@2bits m4 will have to be a keg.

@2bits

This comment has been minimized.

Show comment
Hide comment
@2bits

2bits Feb 26, 2012

Contributor

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

Contributor

2bits commented Feb 26, 2012

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

@adamv adamv reopened this Feb 26, 2012

@adamv

This comment has been minimized.

Show comment
Hide comment
@adamv

adamv Feb 26, 2012

Contributor

Reopening since discussion is still going on here...

Contributor

adamv commented Feb 26, 2012

Reopening since discussion is still going on here...

mxcl added a commit that referenced this issue Feb 27, 2012

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

This comment has been minimized.

Show comment
Hide comment
@camillol

camillol Feb 27, 2012

Contributor

@mxcl so the current autotools require GNU libtool?

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

Contributor

camillol commented Feb 27, 2012

@mxcl so the current autotools require GNU libtool?

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

@mxcl

This comment has been minimized.

Show comment
Hide comment
@mxcl

mxcl Feb 27, 2012

Member

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

Member

mxcl commented Feb 27, 2012

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

@anatol

This comment has been minimized.

Show comment
Hide comment
@anatol

anatol Feb 29, 2012

Contributor

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

Contributor

anatol commented Feb 29, 2012

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

@camillol

This comment has been minimized.

Show comment
Hide comment
@camillol

camillol Mar 1, 2012

Contributor

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

Contributor

camillol commented Mar 1, 2012

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

2bits pushed a commit to 2bits/homebrew that referenced this issue Mar 1, 2012

Nibbles 2bits
libtool 2.4.2
Upgrade libtool to version 2.4.2 per mxcl req in #9179

@2bits 2bits referenced this issue Mar 1, 2012

Closed

libtool 2.4.2 #10610

@mxcl

This comment has been minimized.

Show comment
Hide comment
@mxcl

mxcl Mar 1, 2012

Member

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

Member

mxcl commented Mar 1, 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.

@mxcl

This comment has been minimized.

Show comment
Hide comment
@mxcl

mxcl Mar 2, 2012

Member

I believe everything we can do is fixed.

Member

mxcl commented Mar 2, 2012

I believe everything we can do is fixed.

@mxcl mxcl closed this Mar 2, 2012

@jfirebaugh

This comment has been minimized.

Show comment
Hide comment
@jfirebaugh

jfirebaugh Mar 2, 2012

Contributor

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

Contributor

jfirebaugh commented Mar 2, 2012

@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

This comment has been minimized.

Show comment
Hide comment
@mxcl

mxcl Mar 2, 2012

Member

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

Member

mxcl commented Mar 2, 2012

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

jacknagel added a commit that referenced this issue Mar 2, 2012

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>

etehtsea added a commit to etehtsea/homebrew that referenced this issue Mar 3, 2012

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.

briansniffen pushed a commit to briansniffen/homebrew that referenced this issue Mar 10, 2012

Nibbles 2bits Brian Sniffen
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>

Sharpie pushed a commit to Sharpie/homebrew that referenced this issue Jun 18, 2012

Sharpie pushed a commit to Sharpie/homebrew that referenced this issue Jun 18, 2012

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.

Sharpie pushed a commit to Sharpie/homebrew that referenced this issue Sep 12, 2012

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.

Sharpie pushed a commit to Sharpie/homebrew that referenced this issue Sep 12, 2012

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>

snakeyroc3 pushed a commit to snakeyroc3/homebrew that referenced this issue Dec 17, 2012

snakeyroc3 pushed a commit to snakeyroc3/homebrew that referenced this issue Dec 17, 2012

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.

snakeyroc3 pushed a commit to snakeyroc3/homebrew that referenced this issue Dec 17, 2012

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>

@xu-cheng xu-cheng locked and limited conversation to collaborators Feb 16, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.