<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 12, 2016, at 7:45 AM, Karl via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><div class=""><div class=""><br class="">So I’ve been working on cross-compiling for ARM, and it seems pretty good - only a bit of refactoring of the build script really needed. It’s a popular request, the lack of which is hindering lots of people and businesses who would like to experiment with swift on their ARM-based devices.<br class=""><br class="">The thing that’s really missing before I can propose merging these changes is running the in-tree tests (swift/tests/ folder) to validate the products. I basically want to copy that folder in to a package and run it on the target device, but I’m not really sure how to do that with lit. I’ve built the unit test binaries (the ones which statically link against the runtime), and those obviously are easy enough to package and script for out-of-tree use.<br class=""><br class="">Can anybody help with this?</div></div></blockquote><br class=""></div><div>You should look at the iOS device and iOS simulator machinery in swift/test/lit.cfg for one solution. Both cases use lit substitutions like %target-run to execute a helper tool that can run the test in the appropriate environment and collect the output. Our iOS device testing tool is not open-source, but it uploads a test's source and build directories to the device, runs the test executable on the device, and collects stdout and stderr and any output files. Any other tools used by the test script such as FileCheck still run on the test hosting machine, not on the target device being tested.</div><div class=""><br class=""></div><div class="">Some of the test scripts are complicated, interleaving compile commands and execution commands, so they can't be cleanly separated into a cross-compilation step and an on-device execution step. The %target-run mechanism allows on-device execution without forcing test authors to separate the device-side content.</div><br class=""><div class=""><br class=""></div><div class="">-- </div><div class="">Greg Parker <a href="mailto:gparker@apple.com" class="">gparker@apple.com</a> Runtime Wrangler</div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>