DeinAlptraum wrote: I am unfortunately not at all familiar with how exactly the other tests are integrated and produce the outputs you described: > One problem with all these approaches, as I'd already mentioned, is that the > test outcome isn't properly reported, nor can one use the usual machinery to > XFAIL the test or declare it UNSUPPORTED. That's all hardcoded inside > test/CMakeLists.txt.
and couldn't find much on it either, but that sounds like > Alternatively, as I suggested, one could wrap the actual python -m unittest > discover invocation with a check if libclang.so is loadable at all, only then > running the actual test. is pretty much the way to go here: wrap the `unittest` call in an additional script that adapts the exit code and output format to what is used by the other tests, and then also add additional platform checks into that script. You mentioned the problem of checking loadability at cmake time, but is this really necessary? Such a wrapper script could still parse the failure exceptions and emit an `XFAIL` at run time if `wrong ELF class: ELFCLASS32` is encountered. But also, wouldn't you be able to check this at cmake time just by probing if we are on a 64bit system but building 32bit? https://github.com/llvm/llvm-project/pull/142353 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
