rorth wrote: > 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.
Indeed: one should move the test directory to (say) `clang/test/bindings/python` and add a script using the proper `lit` syntax. See e.g. `llvm/utils/lit/tests/*.py`. This way one can use the full set of `XFAIL:` etc. directives and automatically gets the expected output. This way one wouldn't even have to write the necessary `lit.*` scripts: it's all handled by the preexisting `clang` test framework. > 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 that's building 32bit? Not at all: I just mentioned that attempt to describe why something along the lines of `RUN_PYTHON_TESTS` cannot be used here. It would even be easier (as I described) to just run a minimal script as described above first and only if that works run the actual tests. I'm pretty certain that it's way more reliable to just try loading `libclang.so` and react to failures, rather than trying to deduce the situation indirectly. This is quite similar to software that tries to reason if some filesystem access is possible rather than just trying it and let the kernel do its work (accept or reject the request). As in that case, there are so many factors that could affect this (like using a 32-bit `python` even on a 64-bit system) that would render all guesswork moot. 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
