Hardcoding Xcode.app

Ken Cunningham ken.cunningham.webuse at gmail.com
Fri Oct 9 20:36:53 UTC 2020


and if we're coding this in somewhere to get all systems, it's this:

xcode-select -print-path

I already fixed that particular thing in base once, so somewhere in base this is already being called...


Ken


On 2020-10-09, at 1:14 PM, Andrew Janke wrote:

> Just one data point here, but as a sometimes Mac developer, I need to have multiple versions of Xcode installed side-by-side, and always rename them to Xcode-<version>.app; there's no /Applications/Xcode.app on my boxes. This isn't a standard thing, so on my system, `xcode-select -p` is the only reliable way of locating my Xcodes. I think other devs from the Homebrew side do the same thing, so you may have users in a similar situation too.
> 
> I believe that calling `xcode-select -p` is the standard system-provided way of locating Xcode and/or its related toolchain.
> 
> Cheers,
> Andrew
> 
> On 10/9/20 3:58 PM, Christopher Chavez wrote:
>> Can MacPorts hardcode references to Xcode.app, by assuming it is at /Applications/Xcode.app (as when installed from the App Store), and/or that it will remain wherever it was found and won't ever be moved/deleted?
>> 
>> I would think the answer is "no": it is outside of MacPorts' control, and some users have reason to switch between multiple installed Xcode versions.
>> 
>> See https://trac.macports.org/ticket/58378#comment:7 . I think I have come across other instances of this issue, but can't remember where.
>> 
>> 
>> Christopher A. Chavez
> 



More information about the macports-dev mailing list