I’m working on the Templight template profiler / debugger. I’m trying to remove it from the main-line Clang code and make it a tool. So far, it looks like that will be fairly easy to do, except for one thing.
The problem is that I need to invoke the full-blown Clang compiler, with all of its options (driver / frontend options), otherwise the profile readings will not be representative of the real compilation runs. All those options, it appears, are gathered up in this single global file “Driver/Options.td” (where the templight options have been placed for the moment). I don’t want to pollute Options.td with the additional options I need for templight. I’ve hit a snag where I cannot find a reasonable way to integrate my additional options.
All the other clang tools seem to be using llvm::cl (LLVM’s command-line utility functions) to create and parse their arguments, and it seems like a pretty OK solution. But Clang’s front-end uses this other hand-written code (that uses Options.td), starting from CompilerInvocation::CreateFromArgs, as far as I can tell. I tried to dig into that part a bit, but it’s a complete mystery to me at this point, and of course, no documentation nor comments to help.
The problem is that both try to catch the “-help” and “-version” options. Both have redundant options (I think). Both rely on global information that they assume to be exclusive. Both don’t like unknown options… and so on… they just can’t be used together, they seem mutually exclusive.
So, my question is simply, how can I do this?
I’m lost. On one side, migrating all Options.td into llvm::cl would be insane. And on the other side, the Options.td-based command-line option parsing from clang’s front-end seems like an impenetrable monolith that does not allow simple added-on options. Please tell me that I’m wrong! Please!
Thanks, and hope to hear from you guys,