chelcassanova wrote: > Yes, as a user, if you want to point to a preexisting executable, you'd still > set it in LLDB_RPC_GEN_EXE, but that variable is empty if the user didn't set > anything, and then when the cmake functions either use the user supplied > value, or a locally compiled one, the resolved value is set in > lldb_rpc_gen_exe.
Noted, I'll change how we set the variable for the tool. > But this seems to assume that everybody's cross builds are done in some > specific sequence, with regards to how LLVM_HOST_TRIPLE and > LLVM_DEFAULT_TARGET_TRIPLE are set (in my case, I just cross build with one > single step, and both of those are set to the same in that single stage) - so > I'm not really sure if we can use them like this for detecting what kind of > situation we are in. > The safest, with regards to cross builds, probably is to default to not > enabling this when cross compiling, unless either > LLDB_CAN_USE_LLDB_RPC_SERVER or LLDB_RPC_GEN_EXE is set by the user. Given how many configurations there are to account for here this does look to be the best option. > Yes, but it's also (theoretically) possibly to be doing a universal build for > 2 architectures, while neither of them is the native host one; so you can't > generally assume that one of them is the host architecture. So for that case > it's probably fine to just pick the first/any architecture out of the ones > included. Hm, I hadn't thought about it that way. In that case then we can modify this to process files for the first architecture for the header files. 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
