[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