[PATCH] D126397: [pseudo] Fix pseudo-gen usage when cross-compiling
Sam McCall via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Tue May 31 08:07:27 PDT 2022
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
More information about the cfe-commits
mailing list