remote-run uses rsync instead of sftp server. Some of the tests were
incorrectly labelled as requiring sftp server. Fixed those and replaced
the requirement with rsync.
The current remote-run implementation only works if rsync is located at
`/usr/bin/`, which isn't always the case. FreeBSD installs rsync to
`/usr/local/bin` as it is not installed in the base system by default.
Relax the script to accept rsync on any path.
`remote-run` should look in the environment for input/output paths as
well as considering command line arguments.
With this change, `test/Runtime/Paths.cpp` should work for remote testing
and device testing.
rdar://106294557
Not only does this give us a huge speed-up, it also works around a problem
where sftp doesn't always update the modification time, which causes random
test failures.
rdar://88179140
Not all the tests are possible to run on Windows since they expect a
Unix-like shell environment. However, the rest of the tests can be
accommodated. This actually found an issue in the implementation.
Since the implementation assumes the target is POSIX/Unix-y, we should
use posixpath rather than os.path which uses the host's path style.
Really we ought to clear out "%t*", but running wildcards with 'rm'
scares me a little too much for that. This still fixes a handful of
tests that were relying on %t being an empty directory.
Note that this doesn't interfere with generated files persisting
between %target-run invocations; they'll be downloaded and then
re-uploaded as long as they're mentioned in the invocation.
This is mostly important to allow remote-run to be used to upload
files generally, while still using the same interface and arguments
that will be used to actually run executables.
(instead of locally)
The primary use case I'm looking at is easier testing across macOS
versions, but it could also be used for cross-compilation tests in
general (someday).
