<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">So, trying to quickly reply to what I think may be a high-level point of confusion that we should sift through early:</div><div class="gmail_quote"><br>
On Fri, Aug 29, 2014 at 8:53 AM, Chris Bieneman <span dir="ltr"><<a href="mailto:cbieneman@apple.com" target="_blank">cbieneman@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

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

</blockquote><div><br></div><div>I think all of this comes down to the point you make below: </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div></div><div>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.<br>

</div></blockquote><div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div><br></div><div>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?</div>
</div></div></div>