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

[Chandler Carruth]

On Fri, Aug 29, 2014 at 1:38 PM, Chris Bieneman <cbieneman at apple.com> wrote:

> While it is true that we probably don’t need to allow the libraries to
> mess around with positional parameters, non-hidden options are (I think) a
> different story. If you look at include/llvm/CodeGen/CommandFlags.h, there
> are a number of flags defined here that are not positional, not hidden, but
> only relevant to the CodeGen library. It is probably reasonable that these
> flags be transitioned to the new API, but they also should be exposed on
> the command line.
>

So, the 'hidden' flags are *all* exposed on the commandline, they just
aren't in the *help* output.

My thinking (which perhaps is wrong) is that the library options of this
form probably shouldn't be in the help output. The help output should
probably talk about the tool commandline flags which drive actual API knobs
in constructors of things.


>
> Aside from those options there are probably very few cases where it
> actually makes sense for library options to not be hidden, although I must
> add the caveat that I’m sure there are plenty of library options that are
> not hidden today and making this change will make them hidden. I’m ok with
> this, but it does change one of my original goals because it will actually
> modify the behavior of the command line.
>

This should only change the behavior of '-help' which I think is fine.

> 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?
>
>
> How do you feel about also providing a fluent-style API for toggling the
> (hopefully) uncommon options?
>

I think that if we have optional things that don't make sense as one or two
unsurprising optional arguments, the fluent API design is the right one.

But I'd like to understand what those optional properties are. Currently,
all of the ones we've discussed seem fine to either be required, or be
completely omitted.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140829/1b5cfce7/attachment.html>