This is an alternative approach to D54731. Instead of allow the user to invoke arbitrary python code directly from inside of a test, this patch adds a python script called build.py which we can use the existing substitution system for. For example, we could write something like:
RUN: %build --arch=32 --source=%p/Inputs/foo.cpp --output=%t.exe --mode=compile-and-link
Currently, the build script requires you to pass an explicit compiler, so you would need to pass something like --compiler=path/to/clang++, and it will fail without this. So this isn't quite ready for immediate use. We need to figure out how to get that compiler from CMake into this script. Maybe it means bringing back LLDB_TEST_COMPILER (sigh). Maybe it means auto-detecting the most appropriate compiler by looking in the tools dir, perhaps with something like an additional command line --find-toolchain=msvc or --find-toolchain=clang.
We have some tests right now that require MSVC, so while we can always just keep using a cl.exe command line, it would be nice to be able to port these over and say something like
RUN: %build --find-toolchain=msvc --arch=32 --source=%p/Inputs/foo.cpp --output=%t.exe --find-toolchain=msvc --mode=compile-and-link
For now though, I've tested this on the command line with an explicit --compiler option, and it works with clang-cl + lld-link as well as cl.exe + link.exe, using both Python 2 and Python 3.
I have not implemented the GCC/clang builder yet, although I plan to do that in followups.
Note that at least for Windows, this new builder is significantly better than our existing method of using run lines, because it has advanced toolchain detection logic. Our existing scripts fail when being run from inside of Visual Studio and they also don't allow building an explicit architecture for technical reasons, but with this method we can support both.