This is an archive of the discontinued LLVM Phabricator instance.

[lit] Allow llvm's build and test systems to support paths with spaces
Needs ReviewPublic

Authored by bd1976llvm on Jan 26 2017, 9:28 AM.
Tokens
"Like" token, awarded by nasalodor.

Details

Summary

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.)

Diff Detail

Event Timeline

bd1976llvm created this revision.Jan 26 2017, 9:28 AM

I also ran the lit testsuite on Linux (It doesn't work on windows.)

Can you clarify what you mean by this? Are you referring to test-suite ( http://llvm.org/docs/TestingGuide.html#test-suite ) or something else?

docs/GettingStartedVS.rst
59

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.

I also ran the lit testsuite on Linux (It doesn't work on windows.)

Can you clarify what you mean by this? Are you referring to test-suite ( http://llvm.org/docs/TestingGuide.html#test-suite ) or something else?

lit has it's own set of tests that have to be run separately to the llvm lit tests, see comments in llvm/utils/lit/README.txt

MatzeB edited edge metadata.Jan 26 2017, 11:05 AM

I trust that this patch fixes the issues we have today and that bugpoint issue really should be fixed.

On the other hand I am not sure we will be able to keep this working consistently in a project with hundreds of comitters. So maybe we should just make our life easier and declare this an unsupported configuration. I would propose to add this to our toplevel CMakeLists.txt:

if(CMAKE_SOURCE_DIR MATCHES " " OR CMAKE_BINARY_DIR MATCHES " ")
  message(WARNING "Spaces in the path to the source or build directory are"
  " supported on a best-effort basis. We recommend to use paths without spaces.")
endif()

Would it make sense to split this into

  • cmake changes (look good to me)
  • test changes (they all look good to me)
  • lit changes (I have to find more time to read/think about those)
  • bash script changes (they look good to me)
test/lit.cfg
334

Escaping spaces is probably a first step, but wouldn't we rather need a (posix?) shell escape mechanism? (maybe python shlex.quote/pipes.quote?)

bd1976llvm added a comment.EditedJan 26 2017, 3:45 PM

I trust that this patch fixes the issues we have today and that bugpoint issue really should be fixed.

On the other hand I am not sure we will be able to keep this working consistently in a project with hundreds of comitters. So maybe we should just make our life easier and declare this an unsupported configuration. I would propose to add this to our toplevel CMakeLists.txt:

if(CMAKE_SOURCE_DIR MATCHES " " OR CMAKE_BINARY_DIR MATCHES " ")
  message(WARNING "Spaces in the path to the source or build directory are"
  " supported on a best-effort basis. We recommend to use paths without spaces.")
endif()

Really like this. However, I link the idea of adding a space in the path to one of the build bots (which @rnk states would be achievable) better. Therefore, I will simply remove the paragraph instead.

Would it make sense to split this into

  • cmake changes (look good to me)
  • test changes (they all look good to me)
  • lit changes (I have to find more time to read/think about those)
  • bash script changes (they look good to me)

Ok - great suggestion. However, I will wait until this review is accepted before splitting up the change. In the interest of keeping everything together for review. Reducing the potential for confusion is important :)

docs/GettingStartedVS.rst
59

This document only refers to building LLLVM not any of the other projects e.g: clang, lld etc...
CMake works with paths with spaces. This change adds the ability for lit to support them. Therefore, I think the "has support for" is justified. However, I don't think that there are any build bots that are testing this. That's why I wanted a line saying that the tests might have rotted.

rnk edited edge metadata.Jan 26 2017, 4:02 PM

Thanks for tackling this!

docs/GettingStartedVS.rst
59

Honestly I would remove this paragraph altogether. The best documentation is the kind that doesn't need to exist. It'd be good to add a space to the build directory of some Linux buildbot at some point to ensure that this doesn't regress. I don't think we need a special bot configuration for paths with spaces.

test/lit.cfg
334

+1, it should be the opposite of whatever the lit shell does for tokenization, which is roughly to follow bash quoting rules minus variable expansion.

utils/lit/lit/TestRunner.py
736

I can't find any tests using these substitutions. Any reason not to remove them? At least don't add %^:s without a clear use case for it.

bd1976llvm added inline comments.Jan 27 2017, 4:21 AM
test/lit.cfg
334

We don't need one right now. Why not accept this as an improvement and leave the implementation of a more general escaping mechanism for when/if it is required in the future?

bd1976llvm added inline comments.Jan 27 2017, 7:31 AM
utils/lit/lit/TestRunner.py
736

I wanted to add %^ versions for all of the existing substitutions so that the ability to cope with spaces in paths is available. I actually can't find any tests using the %:[sSptT] substitutions. Do you think that I can remove these. If out of tree tools need them they can add them to local lit config files.

bd1976llvm added inline comments.Jan 27 2017, 8:10 AM
utils/lit/lit/TestRunner.py
736

Actually, %:[sSptT] are used in a few tests in LLD.

bd1976llvm updated this revision to Diff 86054.Jan 27 2017, 8:21 AM

Removed paths in spaces warning from the getting started with llvm and visual studio doc. This is because it would be better to simply change one of the build bots to test this and commit to supporting it going forward!

bd1976llvm edited the summary of this revision. (Show Details)Jan 30 2017, 2:12 AM
bd1976llvm added inline comments.Feb 1 2017, 3:36 AM
test/lit.cfg
334

Actually, the lit shell already knows that escape characters are different on windows and Linux. See: https://gitlab.crest.iu.edu/lvoufo/conceptclang/commit/e9201f5ced4ba3b19d4e548deb8e8d3b461f77ab. This patch just extends that idea to allow escape characters on windows rather than just ignoring them.

bd1976llvm retitled this revision from Allow llvm's build and test systems to support paths with spaces to [lit] Allow llvm's build and test systems to support paths with spaces.Feb 1 2017, 4:34 AM
bd1976llvm updated this revision to Diff 87389.EditedFeb 7 2017, 3:52 AM

I did some more testing of this patch. It turns out that in my testing on linux I had a space in the path to the llvm source code directory but not a space in the path to the build directory. Adding a space in the path to the build directory revealed some problems with the original patch that this new patch addresses.

  1. Needed to quote one more argument in the AddLLVM.cmake for --version-script
  2. On Linux the "%/[STpst]" substitutions were replacing the '\' escape character with '/'. I have reworked the default substitutions code so that normalization is done before escaping.
  3. I have escaped spaces in paths for more substitutions in lit.cfg
chandlerc edited edge metadata.Feb 13 2017, 9:44 AM

So, we have a system that does *not* handle spaces in paths well. I would really like to continue to use the more restrictive rules for lit test names.

I'm happy to have fixes that let things be checked out and built in a path with spaces, but I'd like to require the paths *within* LLVM to continue to not have spaces. Those will work on all systems, whereas paths with spaces will make some users have a (much) harder time integrating with LLVM.

bd1976llvm added a comment.EditedFeb 15 2017, 4:51 AM

So, we have a system that does *not* handle spaces in paths well. I would really like to continue to use the more restrictive rules for lit test names.

I'm happy to have fixes that let things be checked out and built in a path with spaces, but I'd like to require the paths *within* LLVM to continue to not have spaces. Those will work on all systems, whereas paths with spaces will make some users have a (much) harder time integrating with LLVM.

I like this constraint. Unfortunately, as a side-effect of supporting things being checked out and built in a path with spaces, this patch does add the support needed to commit code into paths with spaces within LLVM.

Do you think I need to modify the patch so that CMake/lit actively reject paths with spaces - to prevent such paths getting into llvm?

I would like to point out that if you proactively reject all paths with spaces, you wouldn't be able to add additional tests that would test support for paths with spaces ;-). While I agree that we should avoid spaces whenever possible, I think it would be reasonable to add tests for paths with spaces wherever we expect them to be well-supported and want to avoid regressions.

bd1976llvm added a comment.EditedFeb 15 2017, 5:41 AM

I would like to point out that if you proactively reject all paths with spaces, you wouldn't be able to add additional tests that would test support for paths with spaces ;-). While I agree that we should avoid spaces whenever possible, I think it would be reasonable to add tests for paths with spaces wherever we expect them to be well-supported and want to avoid regressions.

True :) it would be hard to write explicit tests for paths with spaces.

An earlier reviewer (@rnk) suggested that we could modify one of the build bots to add a space in the path to the llvm source tree and the build directory. This would allow the support to be maintained without explicit tests.

I would like to point out that if you proactively reject all paths with spaces, you wouldn't be able to add additional tests that would test support for paths with spaces ;-). While I agree that we should avoid spaces whenever possible, I think it would be reasonable to add tests for paths with spaces wherever we expect them to be well-supported and want to avoid regressions.

You could add to lit's own tests a simple test tree under a path with a space and that would seem fine?

My goal is that *within* a lit test tree, the paths of the files that lit is walking don't have spaces.

After the discussion regarding Bugpoint I've made the change myself in patch D29940. Any input would be appreciated.

I would like to point out that if you proactively reject all paths with spaces, you wouldn't be able to add additional tests that would test support for paths with spaces ;-). While I agree that we should avoid spaces whenever possible, I think it would be reasonable to add tests for paths with spaces wherever we expect them to be well-supported and want to avoid regressions.

You could add to lit's own tests a simple test tree under a path with a space and that would seem fine?

My goal is that *within* a lit test tree, the paths of the files that lit is walking don't have spaces.

Right. Thanks for the comments.

I was initially going to go back to the position that we don't want space in paths anywhere inside the svn repro and we don't need any tests.

However, that means that any work on lit could easily break support for spaces in paths.

Therefore, I will add a "spaces in paths" test to the lit test suite and update the patch.

I am now opposed to adding explicit checks to lit and CMake for spaces in paths within llvm as this is just not needed. People are just not going to start doing this IMO.

bd1976llvm updated this revision to Diff 89192.Feb 21 2017, 4:57 AM

Added tests in "utils/lit/tests/sp aces" to check that spaces in paths are handled correctly.

This does mean that there is now a directory in the repository with a space in its name.

Apologies for the slow update to this :(

rnk added a comment.Mar 1 2017, 10:47 AM

@chandlerc are you happy with the lit test as is checked in with paths with spaces? It's out of the way for any consumer who isn't trying to test lit directly.

Other than that I think this is good.

utils/lit/tests/sp aces/spaces-in-paths.py
3

We could avoid checking in paths with spaces by doing something like:

RUN: mkdir "path with space"
RUN: cp %S/Inputs/check-for-spaces.py "path with space"
RUN: cd "path with space"
RUN: %{lit} -j1 -v check-for-spaces.py
bd1976llvm added inline comments.Mar 2 2017, 2:38 AM
utils/lit/tests/sp aces/spaces-in-paths.py
3

Nice suggestion! Lets see what others think about allowing *just one space* into the repo :)

modocache resigned from this revision.Nov 21 2019, 8:11 PM