Hi! I'm a developer on the Drizzle project, and we're currently replacing the home-grown getopt wrapper we inherited from the MySQL codebase with Boost.Program_options. So far, we're thrilled and it's going great, so thanks! We've focused on the client utilities to start, but as we're coming up on the server, we have an issue that we have an internal solution for, but which seems like it might be something that could be more generally useful, so I thought I'd mention it here, and if there is any interest, I can work up a proper code submission. The situation has to do with plugin modules and option names. In our current system, we enforce an option name prefix that matches the module name. For instance, if you are the InnoDB plugin author, you would declare an option named "buffer_pool_size" which would be presented to the user as "--innodb_buffer_pool_size", and the server/plugin registration handles prepending the module name to the option name for you. (you cannot choose to not do this) For those following along at home, you'll notice the _ we're using for the concatenation - we're happy changing that to be a "." so that the program_options config file sections will work in a sensible way. Our approach to doing this with Boost.Program_options at the moment is to wrap options_description_easy_init in a class. Something like: class DRIZZLED_API options_context { const std::string &module_name; po::options_description_easy_init &po_options; std::string prepend_name(const char *name); public: options_context(const std::string &module_name_in, po::options_description_easy_init &po_options_in); options_context& operator()(const char* name, const char* description) { std::string new_name(module_name); new_name.push_back('.'); new_name.append(name); po_options(new_name.c_str(), description); return *this; } ... }; Then in server plugin registration, a context is created around the real program_options and is is handed to the plugin module: module.register_options(options_context(module.get_name(), commandline_options.add_options()); 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()); And given the mapping of config file sections to name-dotted prefixes, it seems like it wouldn't be a ridiculous addition. Is anybody interested in me reworking what we end up with to be usable or applicable back to the Boost core? Thanks! Monty