Skip to content
This repository has been archived by the owner on Jul 4, 2023. It is now read-only.

Compiler location #9535

Closed
jacknagel opened this issue Jan 11, 2012 · 9 comments
Closed

Compiler location #9535

jacknagel opened this issue Jan 11, 2012 · 9 comments

Comments

@jacknagel
Copy link
Contributor

Related: #6852, #9179, #9524

I think this is a separate issue from "compiler selection" (i.e. fails_with), and probably deserves priority at this point.

We're getting close to the XCode 4.3 release, and it removes the option to install the UNIX tools to /usr/bin. Here is a list of where things are located: https://gist.github.com/1591451 We'll need to deal with this without having to tell users to "add such and such directories to your PATH", so...

There are wrappers installed to /usr/bin (see https://gist.github.com/1592925) for xcodebuild and xcrun. So far MacPorts has done this to aid in locating things. We could certainly do this, maybe something along the lines of

def find_developer_tool name
  case name
  when "gcc-4.0", "gcc-4.2"
    # look in /usr/bin (and /usr/local/bin for gcc-4.2) first, 
    # then shell out to `xcrun` if necessary
  else Pathname.new(`xcrun -find #{name}`.chomp)
  end
end

possibly special casing some other tools if we want to look in other places first. We would need to utilize this to find these tools/symlinks to tools:

cc
clang
llvm-gcc
install_name_tool
otool
strip
make
# others?

An alternative approach might be to add something like HOMEBREW_PATH which gets set up at runtime, and then implement find_developer_tool as a wrapper around which, e.g.

def find_developer_tool name
  path = `PATH=#{HOMEBREW_PATH} which #{name}`.chomp
  Pathname.new(path)
end

or something like that (and is probably faster than the xcrun wrapper). This would also be gentler to users of the osx-gcc-installer.

Further, XCode 4.3 no longer contains autotools. We might have to bite the bullet here and allow in keg-only builds of these things, declaring them as build-time deps of the formulae that require them (on systems with XCode 4.3, of course).

@adamv @Sharpie @mxcl @MikeMcQuaid @mistydemeo

Thoughts?

@adamv
Copy link
Contributor

adamv commented Jan 11, 2012

Xcode 4.x makes me tired.

@adamv
Copy link
Contributor

adamv commented Jan 11, 2012

But yeah we need to take all of the hard-coded tool paths out of Homebrew and use some real machinery to locate them in OS and Xcode specific ways.

I'm in no rush to move to Lion at home, actually, at least until they rev the iMac models. So it's still Snow Leopard / Xcode 3.2.x for me here.

Maybe Xcode 4.3 / Lion is a sort of Homebrew 2 forcer? I dunno.

@jacknagel
Copy link
Contributor Author

I'm in no rush to move to Lion

I'm not, either. I have been willing to keep upgrading my XCode to get the latest compilers, so long as it doesn't break things, but I think 4.2 is the final SL release. I haven't seen anything about a 4.3 SL version.

@tonyarnold
Copy link

Have a quick look through the dev forums when you have time — the Xcode engineers have said a few times that they're not done with 4.3's UNIX tool installation yet (as of Developer Preview 3). I wouldn't put too much energy into this beyond the "make it flexible" part of the issue — Xcode 4.3 is still in flux by the sounds of it.

@jacknagel
Copy link
Contributor Author

Awesome, hope that's the case.

@MikeMcQuaid
Copy link
Member

Cool. I'll upgrade to Xcode 4.3 the day it's out so will try and fix it then.

@samueljohn
Copy link
Contributor

The day has come.

@MikeMcQuaid
Copy link
Member

Move 4.3 discussion to #9179.

@jacknagel
Copy link
Contributor Author

Closing to keep the discussion contained to one thread.

@Homebrew Homebrew 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.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants