summaryrefslogtreecommitdiff
path: root/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
diff options
context:
space:
mode:
authorNico Weber <nicolasweber@gmx.de>2019-03-08 13:01:58 +0000
committerNico Weber <nicolasweber@gmx.de>2019-03-08 13:01:58 +0000
commitc3130a8a52b9cf29190eb33c3bd4d91ba49403e1 (patch)
tree82be5e1ea7f4af3590416ce7b78382e74b1863b0 /lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
parent38e6bcc14b6b0bc56f21b224668d69204c5ae812 (diff)
gn build: Unbreak finding a working `gn` on $PATH on Unix after r355645
From the Python subprocess docs: If shell is True, it is recommended to pass args as a string rather than as a sequence. [...] If args is a sequence, the first item specifies the command string, and any additional items will be treated as additional arguments to the shell itself. Prior to this change, the `--version` would be passed to the shell, not to a potential gn binary on $PATH, and running `gn` without any arguments makes it exit with an exit code != 0, so the script would think that there wasn't a working gn binary on $PATH. Fix this by following the documentation's recommendation of using a string now that we pass shell=True. I tested this on macOS and Windows, each with the three cases of - no gn on PATH (should run gn downloaded by get.py if present, else suggest running get.py) - broken gn wrapper on PATH (should behave like the previous item) - working gn on PATH (should use gn on PATH) llvm-svn: 355694
Diffstat (limited to 'lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp')
0 files changed, 0 insertions, 0 deletions