<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 29, 2014 at 1:38 PM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>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.</div>
</div></blockquote><div><br></div><div>So, the 'hidden' flags are *all* exposed on the commandline, they just aren't in the *help* output.</div><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br></div><div>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.</div>
</div></blockquote><div><br></div><div>This should only change the behavior of '-help' which I think is fine.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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>
</blockquote><br></div></div><div>How do you feel about also providing a fluent-style API for toggling the (hopefully) uncommon options?</div></blockquote></div><br>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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
</div>