[LLVMdev] [RFC] Removing static initializers for command line options

[Chandler Carruth]

So, trying to quickly reply to what I think may be a high-level point of
confusion that we should sift through early:

On Fri, Aug 29, 2014 at 8:53 AM, Chris Bieneman <cbieneman at apple.com> wrote:

> Oddly enough the argument string IS optional, but you must have either an
> argument string or cl::Positional (but not both). It is probably reasonable
> to define two registerOption() calls one that takes an argument string and
> description, and one that only takes a description and implies
> cl::Positional.
>

I think all of this comes down to the point you make below:

It seems to me like you’re suggesting an end solution where cl::opt still
> exists for tool-specific options, and the register/get API exists for all
> of the other options littered around the compiler. While I’m not going to
> object strongly to this idea because it does serve my purposes (getting rid
> of static initializers in the libraries), I don’t particularly care for
> this. I think fundamentally if we are aiming to provide a better API for
> defining options, I don’t think there is any reason not to use that API
> everywhere and to abandon the existing one completely. If you disagree,
> please let me know.
>

Ah, ok, here we have uncovered what I suspect is the underpinning set of
different assumptions / directions that are creating some of the confusion.
Now that you've put your finger on it (thanks!) I'll try actually address
this. Sorry if this is a bit of a re-statement, but hopefully it'll at
least let you respond directly with where my thinking has gone off the
rails.

So I am definitely trying to design this as a system totally divorced from
the tool-specific options, or actually a command line system of any form.
That's why stuff like positional arguments and the cl::opt tie-ins aren't
showing up in my thoughts and suggestions.  What you say makes perfect
sense if we're building a replacement for *all* of cl::opt's functionality.
While I would be interested in trying to do that (and we already have one
replacement in tree used by Clang and LLD to parse command line options),
I'm suggesting that what the LLVM *libraries* need is something completely
separable from a command line interface, but which is easy to build a
command line interface around.

The way I'm thinking of this is as a generic collection of optional
key->value settings. The libraries don't have any business mucking with
positional parameters, non-hidden options, or the other concerns of a
command line system, and the code it uses (and the APIs it uses) to
register and use these options is a *better* interface when it is narrower
and doesn't have to support these features.

Now, I think we should still be able to expose these via the 'cl::opt'
layer in the tools that are using that layer. But we should also be able to
expose it via an API to say webkit or whomever needs it there. And we
should be able to wrap it in a nicer command line interface in Clang.


Is that a convincing argument for you to restrict the scope of this
interface? Maybe there are other things that you'd like to do here that
motivate going the other direction?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140829/d61b8433/attachment.html>