Hi Liam,
What I would most like to be able to do is process the command line (for example) twice - once in the outer wrapping context, looking for the options that are relvant there, and once in the core engine, looking for the options there. When I try a test app with this structure, though, I get exceptions thrown when any options are encountered that are not included in both the options_descriptions used, which sort of defeats what I'm trying to do - I want to have two distinct sets of options: one for the wrapper, and one for the core, with (little or) no overlap.
I would be happy if I could disable the exception behaviour, allowing the processing to complete and report to me that it encountered some unknown options along the way. This would mean that I would risk ignoring some unknown options in both passes, but I could live with that, I think.
I can see a possible alternative, which requires me to pass the wrapper's options_description to the core engine, get it all parsed there, and pass back the map for examination by the wrapper. This would make some additional work for me, but would probably work fine. I guess I'd just like to know whether the other way of approaching things is going to be supported, or whether there is yet another approach I should consider?
The command line parser in 1.32 version of the library has a mechanism to accept unregistered options. Unfortunately, due to oversight, that mechanism is not available via any public interface. At the moment, I'm cleaning up the command line parser implementation and hope to fix the above problem, too. But I also think you should be able to combine options_description and parse both wrapper and core options at the same time. Something like that: options_description desc; options_description wrapper_options; // .. fill wrapper options desc.add(wrapper_options); desc.add(core::options_description()); variables_map vm; // parse options core::set_options(vm); Any reason this is not OK? - Volodya