labath added a comment. I didn't look at the code in detail, as most of it deals with windows stuff, and I don't know much about those anyway. However, the interesting question for me would be how to make this useful for cross-compiling. Right now that sort of works for NativePDB tests because --compiler=clang-cl implies windows, but that won't help if I want to compile say a linux arm64 binary. I think that instead --arch, we should have a `--triple` argument, which specifies the exact target you want to build for. That can default to "host", and we can have special pseudo-triples like "host32" and "host64", if we want to be able to say "I want to build for a 32-bit flavour of the host arch". That could also make gcc detection easier, since you could just search for `$triple-gcc`.
Another route to take might be to say that this script only supports building for the host, and tests that want to target a specific architecture can just invoke the appropriate compiler directly -- since they know the target arch, they also know the correct compiler option syntax. Plus, these kinds of tests are the ones that are most likely to need fancy compiler command line switches that might be hard to represent generically. In this world, the NativePDB tests would continue to invoke %clang-cl (which would point to the build dir without any fancy logic), and build.py would be used by scripts that just want to build an executable for the host, and don't care much about the details of how this is accomplished (the stop-hook tests are a good example of this). (Among the cosmetic things, I'd suggest to make `--source` a positional argument and enable spelling of `--output` as `-o`, just to make things shorter.) CHANGES SINCE LAST ACTION https://reviews.llvm.org/D54914/new/ https://reviews.llvm.org/D54914 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
