mstorsjo wrote: > > Right - I see. But why does this build configuration have to affect whether > > it should build lldb-rpc-gen or not? Is it because the clang in this build > > can't manage to process the lldb headers (which are built for the current > > host)? > > Right, "the clang in this build can't manage to process the lldb headers" > because they include the target c++ headers, which are not available yet on a > moment of executing the lldb-rpc-gen tool during the cross-toolchain build.
Hmm, that's very odd. At the point when `lldb-rpc-gen` runs, it's supposed to try to parse the headers in the same way as the host compiler does, using the same C++ standard library as the host compiler does. Unless Clang is built with something like `CLANG_DEFAULT_CXX_STDLIB=libc++` though, or a default config file used for all targets, - which then also would apply when using the same Clang (libraries) for the host. > * the lldb-rpc-gen tool depends on the clang libs to scan the lldb headers, > but in our configuration Clang will use just-built libc++ and its header > files. We need to prepare the libc++ headers inside of the build tree before > using clang++/lldb-rpc-gen. Actually IMO the issue is the other way around; if the host build doesn't use libc++ headers, then the lldb-rpc-gen is supposed to parse headers in exactly the same way as the host build as well, not waiting for some target runtimes to be built. > in addition: > > * as far as I know, there is no way to properly configure the build > dependencies and run the lldb-rpc-gen tool after the `builtins` and > `runtimes` builds get ready. > * I know only one way to detect the cross toolchain build -- to compare > LLVM_HOST_TRIPLE and LLVM_DEFAULT_TARGET_TRIPLE, -- but it is not working for > some cases. That's maybe one indication, yes... But as far as I can see, this really boils down to something else; it's not so much about cross vs not cross, it's about "can the currently built clang libraries be used for host compilation/parsing" - and target specific defaults like `CLANG_DEFAULT_CXX_STDLIB=libc++` can be one of the factors that break that. Possibly many more as well. (The fact that your Clang build only supports targeting aarch64 might also factor in, but most of the Clang frontend doesn't require the LLVM backend, at least for parsing headers.) Specifically the case about cross compiling LLVM itself, is another factor though, because if we'd enable building `lldb-rpc-gen` like we do for all other build-time code generation tools, like `llvm-tblgen`, then we end up duplicating 75% of the whole clang build - which we probably don't want to do. > PS. Probably it is optimal to stop trying to detect all these known and > unknown situations and manage building over `option` with OFF by default (may > be except Darwin), but with consideration of the cross builds. Yes, I agree about that. https://github.com/llvm/llvm-project/pull/151603 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
