4 ms·

There's one thing I can't understand about Apple's approach, and that is their pathnames. As good as Swift is, putting it by default in asinine paths like "/Li

There's one thing I can't understand about Apple's approach, and that is their pathnames. As good as Swift is, putting it by default in asinine paths like "/Library/Developer/Toolchains/swift-latest.xctoolchain/usr/bin" doesn't help anybody (and a ton of stuff in OS X is like this). A more Unixy way to do this would be /opt/swift-3.0/bin, where /opt/swift is a symlink to /opt/swift-3.0. Even Apple used to limit the path insanity to merely /Developer/usr/bin. Not sure what happened...

panic 11y ago
Not defending the practice, but you can use 'xcrun' to find and run these binaries. E.g. to find swiftc, you can use 'xcrun -f swiftc', and to run it, 'xcrun swiftc'.
- makecheck 11y ago
  I suppose, though it doesn't tab-complete. :) There's all kinds of reasons to want short paths. Having said that, I can create my own /opt symlink to a long path too.
rsynnott 11y ago
> A more Unixy way to do this would be /opt/swift-3.0/bin, where /opt/swift is a symlink to /opt/swift-3.0. This could cause entertaining problems for people who routinely install both current and beta versions of dev tools (which is relatively common; if you're working on iOS10 features for your new app but still need to release iOS9 updates during the beta period you more or less _have_ to, for instance). I suspect that's why they changed it in the first place.
lobster_johnson 11y ago
The paths are cumbersome, but I wouldn't call them asinine. Apple's toolchains are versioned by SDK. That's why they have xcrun, so you can do things like: # xcrun --sdk iphoneos clang [...] On my system, clang's path is even worse than your example: # xcrun --sdk iphoneos --find clang /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang You're not supposed to remember those paths. Xcode and xcrun remembers them for you. Apple doesn't touch the base OS folders for non-OS software, which is why stuff goes into /Library and /Applications. Besides, (Apple has never used /opt, and doesn't even document it, last I checked: "man hier" doesn't mention it.)

panic 11y ago

Not defending the practice, but you can use 'xcrun' to find and run these binaries. E.g. to find swiftc, you can use 'xcrun -f swiftc', and to run it, 'xcrun swiftc'.

makecheck 11y ago
I suppose, though it doesn't tab-complete. :) There's all kinds of reasons to want short paths. Having said that, I can create my own /opt symlink to a long path too.

rsynnott 11y ago

> A more Unixy way to do this would be /opt/swift-3.0/bin, where /opt/swift is a symlink to /opt/swift-3.0. This could cause entertaining problems for people who routinely install both current and beta versions of dev tools (which is relatively common; if you're working on iOS10 features for your new app but still need to release iOS9 updates during the beta period you more or less _have_ to, for instance). I suspect that's why they changed it in the first place.

lobster_johnson 11y ago

The paths are cumbersome, but I wouldn't call them asinine. Apple's toolchains are versioned by SDK. That's why they have xcrun, so you can do things like: # xcrun --sdk iphoneos clang [...] On my system, clang's path is even worse than your example: # xcrun --sdk iphoneos --find clang /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang You're not supposed to remember those paths. Xcode and xcrun remembers them for you. Apple doesn't touch the base OS folders for non-OS software, which is why stuff goes into /Library and /Applications. Besides, (Apple has never used /opt, and doesn't even document it, last I checked: "man hier" doesn't mention it.)