AaronBallman wrote: > @AaronBallman Can you describe your current plan how driver options are going > to behave in the light of `#embed`?
I'm flexible with how we proceed, so if others have different ideas, feel free to suggest them! But my initial inclination is: * `--embed-dir=<dir>` as a way to specify a search path for `<>` and `""` embedded resources; the quoted form will search the current directory similar to how it behaves for `#include`. I do not envision needing a "system" embedded resources directory, but should such a need arise, we can consider something like `--embed-system=<dir>` to support it. * `-E -dE` as a way to preprocess to a file without exploding the contents of the embedded resource into the preprocessed output (that output could become very large). Then the options for determining makefile dependencies can be updated to consider embedded resources are a dependency and tools like distcc can hopefully cope from there. * As a follow-up, I might consider adding a directive `#embed_base64` that holds base64 encoded file contents of the resource to be embedded. Then we can add `-E -dE64` (or some other option name) to preprocess from `#embed <file>` to `#embed_base64 <encoded contents>` for times when it's not plausible to keep the source and the resource separately. I don't envision that being a directive users would use directly, but instead only for rewriting purposes. Ideally, GCC and Clang can agree on what and how we surface the command line features. https://github.com/llvm/llvm-project/pull/68620 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
