swiftgen 0.5.0 fix

[AliSoftware]

Given this issue, we can't use bottles to install SwiftGen

The Problem

What happens is that being a Swift script, it depends on Swift dylibs that are located in Xcode.app bundle, and the binary's @rpath points to the path to Xcode.app that was used to build the binary, in order to find those dylibs back when running.

If the user's Xcode.app is not in the same location as the Xcode.app used by BrewBot to build the bottle, then the binary will have an incorrect @rpath and the Swift libraries won't be found.

What I tried

Instead of completely remove the support for the bottle, I first tried to fix the installed binary using a post_install, but to no avail, because when trying to run install_name_tool -add_rpath /path/to/Xcode/in/local/machine/Contents/… /usr/local/bin/swiftgen to fix that @rpath, it fails with a Permission Denied error. Here is the post_install code I tried for reference.

def post_install
    if build.bottle?
      # Fix the path to Xcode's Swift dylibs if it's installed via bottle and Xcode is at a different path
      swiftc = Pathname.new `xcrun -find swiftc`
      rpath = swiftc/"../../lib/swift/macosx"
      # Problem here: if the rpath already exists, this command will fail. Can't find a way to check that first
      system(%Q(install_name_tool -add_rpath "#{rpath}" "#{bin/"swiftgen"}"))
    end
  end

Result:

error: /Applications/Xcode 7.0.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: 
can't open input file: /usr/local/Cellar/swiftgen/0.5.0/bin/swiftgen for writing (Permission denied)

Workaround

Even if we find a way to fix it, in the meantime I need to disable the bottle so that users can run it at least on any machine, whatever their Xcode.app path is.

[DomT4]

This is too harsh, IMO. Rather than banning bottles for everyone it would seem to make more sense to check whether Xcode was installed in the default location. Honestly I'd be surprised if there are many people not running Xcode out of /Applications though.

[AliSoftware]

There are a LOT of people having Xcode in /Applications but not named Xcode.app.

Especially now as people (like me) tend to keep an Xcode6.app around for some time for legacy projects, also have Xcode7.app for everyday projects, and also have Xcode7.1beta.app for testing tvOS

[AliSoftware]

Is there any guarantee that the machine BrewBot uses to build the bottle use an Xcode named /Applications.Xcode.app all the time? In that case I can indeed only use the bottle if it's also the case for the user.

[DomT4]

Given a not tiny number of compile scripts specifically check for /Applications/Xcode.app and presume you don't have one unless it is named exactly that, having no Xcode.app is quite risky. You can keep multiple Xcodes, but you'll hit significantly fewer issues if one is kept as the default name.

[DomT4]

Is there any guarantee that the machine BrewBot uses to build the bottle use an Xcode named /Applications.Xcode.app all the time?

On stable OS X versions, yes. On very beta OS X versions it may well be Xcode-beta.app but 10.9, 10.10 & 10.11 are all stable. The first runs Xcode 6.4, the latter two run 7.0.1, all three are /Applications/Xcode.app.

[AliSoftware]

Given a not tiny number of compile scripts specifically check for /Applications/Xcode.app and presume you don't have one unless it is named exactly that, having no Xcode.app is quite risky. You can keep multiple Xcodes, but you'll hit significantly fewer issues if one is kept as the default name.

Sure, but:

• those scripts are being bad citizens, and I prefer to be a good one
• that's not always anybody's choice.

For example in the case of the OP of SwiftGen/SwiftGen#35 (comment) the issue is on CircleCI, not even his own machine. So I think I should still ensure it works on such contexts.

[DomT4]

Of course. Not saying you can't or wouldn't want to work on a fix, just saying that banning everyone from using bottles is probably a bit too broad in this particular situation when we can do a check to see where Xcode is installed and pour if true.

[AliSoftware]

Totally agreed, and just fixed. Thx!

[MikeMcQuaid]

Thanks for your contribution to Homebrew! Without people like you submitting PRs we couldn't run this project. You rock!