sammccall added a comment. In D126397#3547060 <https://reviews.llvm.org/D126397#3547060>, @thakis wrote:
> Should pseudo-gen honor LLVM_USE_HOST_TOOLS too? It looks like it's basically > the same situation. Yes, I agree, it should. I'll send a patch. One caveat here: that there are (too) many possible configurations here, and little documentation or buildbot coverage, so we're kind of fixing this blind. > Maybe it'd make sense to make this a tblgen-based tool? Then this would've > Just Worked.). There are a few reasons it didn't seem like a good fit for tblgen: - it necessarily has a dependency on a separate library clangPseudoGrammar (for now it's conceivably possible to copy into the tablegen backend, but soon this will include the LR automaton generator etc). I didn't see any precedent for this. - tablegen isn't the right format for the input data, and so isn't adding any value except build system bits - this isn't part of clang, and there isn't a clang-tools-extra-tblgen, so we'd need a new clang-pseudo-tblgen in any case. This would solve *some* problems, but not all. > Regarding building native tools while cross compiling - for other tools so > far, we’ve also had the option to pass an option like > -DLLVM_TABLEGEN=path/to/llvm-tblgen. If all the needed native tools are > provided that way, the build doesn’t need to set up the nested native cmake > build while cross compiling. Should we prove a way to do that for this build > time generation tool too? Yeah, it seems reasonable to spend a little bit more cmake complexity for this. I hope it can be done in a few lines (digging into it) esp given how hard it is to maintain non-bot-covered cmake configs. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D126397/new/ https://reviews.llvm.org/D126397 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
