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
`os.uname()` doesn't exist on Windows, so use `platform.machine()` which
returns `os.uname()[4]` on non-Win and (on 64-bit systems) "AMD64" on Windows.
Also use `sys.platform` instead of `platform` to check for Windows-ness for the
file extension in gn.py (get.py got this right).
Differential Revision: https://reviews.llvm.org/D59115
llvm-svn: 355693
Use the system shell to see if we can find a 'gn' binary on $PATH. This solves the error wherein subprocess.call fails ungracefully if the binary doesn't exist.
llvm-svn: 355645
Prebuilts are available for x86_64 Linux, macOS, Windows. The script always
pulls the latest GN version.
Differential Revision: https://reviews.llvm.org/D57256
llvm-svn: 352420
Since people weren't enthused about moving the .gn file to the toplevel in
D56419, here's a script to make gn at least somewhat more pleasant to invoke
(useful for gn clean, gn args --list, gn desc, etc).
Differential Revision: https://reviews.llvm.org/D56565
llvm-svn: 351064
Nico Weber