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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
