Monty Taylor <mordred <at> inaugust.com> writes:
On 06/12/2010 01:20 AM, Vladimir Prus wrote:
Monty Taylor wrote:
It seems like a possibly nicer or more integrated approach would be something that would look like this:
module.register_options(commandline_options.add_options(module.get_name
());
Is anybody interested in me reworking what we end up with to be usable or applicable back to the Boost core?
This sounds similar to something we're doing, where the first argument on the command-line decides the mode of the program. We wanted the convenience of being able to use a single configuration file, but also the convenience of not having "section." prefixes on the command- line. E.g. ##### #/config.ini [mode_1] opt1=... opt2=... optFoo=... [mode_2] opt1=... opt2=... optBar=... #### theProgram mode_1 config.ini theProgram mode_1 opt1=value theProgram mode_1 config.ini opt2=override theProgram mode_2 optFoo=value // error: option not available for mode_2 At the moment we have a (simple, but a bit hacky) solution of prepending the mode onto the command arguments, so +1 for anything that moves code out of our base into the library ;-)
The only concern is that you simplify definition of options, however, it seems that access to options still have to use fully qualified names. Or do you have solution for that as well?
I don't have a solution to that, but you're right, I should really come up with one. I guess my first concern was simply to prevent module authors from accidentally breaking namespace rules - but their code will certainly make more internal sense if they can access options using the same short names.
Is this a case of being able to 'bind' the variables_map to a domain, too?