[Lldb-commits] [PATCH] D54914: Add a generic build script for building test inferiors

[Zachary Turner via Phabricator via lldb-commits]

zturner added a comment.

In D54914#1309700 <https://reviews.llvm.org/D54914#1309700>, @labath wrote:

> 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`.


A triple is one way.  I don't know much about gcc, does it support the same triple format as clang?  clang-cl certainly doesn't support triples since it implies one.  Also, are there any existing use cases for specifying a triple in the lit test suite?  I do agree we will need the ability to support triple specification, but it seems better to do this as a followup.  I don't think it should be too hard as long as we can make some assumptions such as "specification of --triple limits the possible supported compilers", etc.

> 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).

That's another good possibility.

> (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.)

I did both of these in the latest update.  I need to make it possible to specify multiple inputs, but I'll do that in a followup as there's no immediate need for it in any of the tests I converted.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54914/new/

https://reviews.llvm.org/D54914