[llvm-dev] Binary utilities: switch command line parsing from llvm::cl to OptTable (byproduct: drop -long-option?)
Reid Kleckner via llvm-dev
llvm-dev at lists.llvm.org
Wed Jul 7 12:44:51 PDT 2021
On Fri, Jul 2, 2021 at 5:22 PM Mehdi AMINI via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I think part of the confusion on my side in this thread is that when I
> read "binary utilities" I thought first and foremost about `opt` and `lld`,
> while you're using "binary utilities" to refer to what I would call
> "end-user tools".
> I agree with you that tools like clang and lld are in a different category
> than `opt`.
>
> cl::opt as it may not be suitable as-is, but OptTable being not composable
> and not offering any facility to someone building a tool to re-expose
> library options is also quite limited. It seems to me that we need such a
> solution, and it also seems that if we had such solutions it would be
> suitable for all the tools we intend to build using LLVM-based libraries.
> Without any plan to build this though, I'm not trying to block progress on
> your cleanup/improvement of these end-user tools :)
>
I wanted to express my agreement:
- OptTable is reasonable when attempting to implement a closed,
compatible command line interface
- We should not view cl::opt's library registration design as somehow
"evil": There is much room for improvement
So, yeah, for all our GNU-compatible tools, go ahead and use the Option
library.
I think cl::opt has a future in LLVM, but that's worth it's own discussion
thread. The MLIR conventions help a lot, but they still appear to use a
global command line registry, which isn't ideal for some use cases.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210707/fd8ecd55/attachment.html>
More information about the llvm-dev
mailing list