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

[Filip Pizlo]

> On Aug 19, 2014, at 11:09 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> 
>> On 19 August 2014 13:47, Chris Bieneman <beanz at apple.com> wrote:
>> I’d like to propose moving forward with the first phase of my proposal to
>> make the cl::opt structures owned and eliminate global option storage.
> 
> For now, please eliminate only the static constructor and leave the
> storage. Since it seems only a few options that need to be exposed by
> non-command line APIs, we might be able to avoid the need for a
> cl::OptionRegistry::GetValue.
> 
>> I’d
>> also like to add to it that when updating passes I will ensure that each
>> pass that has cl::opts also has a default constructor, an overridden
>> constructor to populate each option, and the corresponding factory methods
>> for the C API.
> 
> And *please* don't add anything to the C api unless someone has a real
> need for that particular interface and there is a good discussion on
> the review thread about it. The C api has more backwards compatibility
> promises, which makes it incredibly painful :-(

This is a good point. I see two sensible options:

1) don't add anything to the C API unless someone specifically asks, as Rafael suggests. 

2) make options passed to passes use some kind of loose coupling, like an array of strings or even better an options object where the user sets key/value pairs by some call (eg. LLVMSetOption(optionObject, keyString, valueString). 

The upside of (2) is that it preserves current functionality and new options can be added easily. The downside is that we'd have to get very particular about whether an option needs to be supported indefinitely if it is ever exposed. Probably nobody wants that strong of a contract. 

-Filip

> 
> Even the C++ api is not free, so I would also only modify a pass
> constructor if someone wants to pass that option for something other
> then llvm development or testing. For that command lines are a
> perfectly reasonable solution.
> 
>> Does this sound reasonable for a first step?
> 
> Removing the static constructors does.
> 
> Cheers,
> Rafael