[llvm-dev] Binary utilities: switch command line parsing from llvm::cl to OptTable (byproduct: drop -long-option?)

[Mehdi AMINI via llvm-dev]

On Wed, Jul 7, 2021 at 12:45 PM Reid Kleckner <rnk at google.com> wrote:

> 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.
>

Indeed, getting rid of the global state would be ideal, but that also seems
much more challenging from an API design point of view: do you have ideas
on this?

In the meantime, to improve the situation with libSupport, I just wrote
https://reviews.llvm.org/D105959
(we're reusing libSupport in various situation and get hit by the eager
registration of cl::opt and other globals in some cases)

-- 
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210713/791b50c8/attachment.html>