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