I'd like to use the program_options library, but am reluctant to require my users to build parts of Boost. Is there a strong reason that this library cannot be header-only?
You can build the necessary Boost CPP files as part of your own build.
Asio (which is header-only) offers the possibility for "optional separate compilation" by including some ".../impl/src.hpp" in a source file and defining either "BOOST_ASIO_SEPARATE_COMPILATION" or "BOOST_ASIO_DYN_LINK", which very nicely lets the user choose which one suits best for his needs. Is there a reason why this isn't done for other libs like program_options, regex, etc., or has it (at least sometimes) just not been done because nobody wanted to do this extra-work? It is a very frequently asked question if/why not there is a header-only version, and although it is sometimes really not possible to make it header-only, most libs should work that way. Furthermore, in my experience specially commercial projects are reluctant to use libraries that have to be shipped with the own product, whereas it is no problem as long as they are "hidden" inside the binary.. Of course there are some disadvantages as shown in the discussion on stackoverflow, but giving the user a choice where possible should hugely increase acceptance and usage of those libraries. Greetings, dib PS: I just tried it with program_options and at least with my programs on linux it works fine, don't know how it is on other platforms or if I was just lucky: copy the src-files from libs/program_options/src to the include/boost/program_options/impl and do it "the asio-way", including the source files in a separate .cpp in my projects.. works fine and no linking is required any more.