[build-script] never expand install prefix as relative path

[karwa]

What's in this pull request?

If the install prefix doesn't begin with a leading /, CMake will expand it as a relative path from the build directory. This leads to strange install trees, where swift, llvm and llbuild (the products which install with CMake) get placed in, for example:
destdir/Spring/Projects/3rdParty/OpenSource/Apple/build/Ninja-ReleaseAssert/swift-macosx-x86_64/swift-3.0.xctoolchain/usr/bin/swift

instead of:
destdir/swift-3.0.xctoolchain/usr/bin/swift

with a parameter: --install-prefix=swift-3.0.xctoolchain/usr

This fixes a regression from #2497. Previously we os.path.abspath-ed the install-prefix in build-script, which looked like it could have even been the cause of the strange trees. So now there's also a comment to explain why we're doing this.

Resolved bug number: (SR-)

---

Before merging this pull request to apple/swift repository:

• Test pull request on Swift continuous integration.

Triggering Swift CI

The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:

Smoke Testing

Platform	Comment
All supported platforms	@swift-ci Please smoke test
All supported platforms	@swift-ci Please smoke test and merge
OS X platform	@swift-ci Please smoke test OS X platform
Linux platform	@swift-ci Please smoke test Linux platform

Validation Testing

Platform	Comment
All supported platforms	@swift-ci Please test
All supported platforms	@swift-ci Please test and merge
OS X platform	@swift-ci Please test OS X platform
OS X platform	@swift-ci Please benchmark
Linux platform	@swift-ci Please test Linux platform

Lint Testing

Language	Comment
Python	@swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

[gribozavr]

If the install prefix doesn't begin with a leading /, CMake will expand it as a relative path from the build directory.

Can we reject non-absolute paths instead? A "prefix" as far as I understand it, is used to move things around in the destroot, for example, into a "secondary" (/usr) or "tertiary" hiararchy (/usr/local), or some vendor prefix (/opt/swift-3.0). I think it makes sense to require an absolute path here, because that's what it will become on the filesystem that we are constructing.

[karwa]

Yes, but you're not always really constructing a filesystem. The toolchains do because they install in a system-wide /Library/Developer/Toolchains. Actually, that's probably bad practice from the toolchains (and installable packages) - they should probably install to a user-local toolchain directory at ~/Library/Developer/Toolchains.

I always use a user-local toolchain directory, so having an absolute path as the install prefix doesn't really make sense. I just set mine to swift-3.0.xctoolchain/usr and copy/symlink it in to the above folder. It doesn't feel right to force an absolute path - sometimes all you care about it the package and you don't know where the final install location will be.

[gribozavr]

I just set mine to swift-3.0.xctoolchain/usr and copy/symlink it in to the above folder.

I'd argue that then swift-3.0.xctoolchain should be a part of the destdir.

[karwa]

I'd go one step further and say that it should be the toolchain-prefix, but that parameter gets automatically set by the build-script by extracting the first path component of the install-prefix, so it has to be there. I tried to change it as part of #2497 but it was too much. We'd still be reviewing it, I think.

It would be nice if the toolchain prefix was made more obvious at some point. Right now it's some kind of hidden magic - it's assumed to be part of your install prefix and if it's wrong your toolchain looks completely wrong and it's not easy to discover why. For now I think there is no situation when we want the path to the build directory inside the install-prefix.

[gribozavr]

OK. This seems harmless to allow for now.

[gribozavr]

@swift-ci Please test and merge