Most major platforms support paths which can contain spaces. Paths with spaces are rare on some systems but they are common on Windows.
LLVM should embrace paths with spaces!
My motivation for this change is that we had a CI system, which we were obliged to use but over which we didn't have control, that checked out source code into sub-directories below a path that contained spaces.
Details
On Windows the build worked out of the box.
On Linux I had to make a few small changes to CMake and bash build scripts to get the build working.
In order to get the lit tests to run I modified lit to escape spaces in substitutions, this change allowed the vast majority of tests to run. I provided a new set of default substitutions containing the windows '^' escape character e.g: %^s, %^t to allow a test writer to use a substitution which does not escape spaces in the (extremely rare) cases where this is required. The main use case for this is where a test writer needs to use a substitution inside of quotation marks - as this would preserve the escape character. I also had to modify tests that used echo to emit lines to a file that is later piped into a process. These tests have been modified to echo quotation marks to surround any paths as these might contain spaces.
One test is still failing: BugPoint/compile-custom.ll. Bugpoint simply does not work with spaces in paths due to naive tokenization of the custom compiler string. See the function lexCommand in bugpoint/ExecutionDriver.cpp.
Testing
I tested this on windows via cmd and and msys and on Linux (bash - ubuntu 14.04).
I also ran the lit testsuite on Linux (It doesn't work on windows.)
I'm not convinced by this message. LLVM as a whole includes various different projects which new users may come to expect from this document to also work in paths with spaces, but AFAICT this commit only affects the base llvm project itself. I'm also not entirely comfortable with the idea that it's essentially saying "it may work, unless we break it". I make no judgement as to whether it's worth making everything work with paths with spaces, but we should probably err on the side of caution and just document that it's not supported if we can't guarantee it.