Add the way to use it as a shared library

[KOLANICH]

I understand, that header-only libs are easy to incorporate into software, but I dislike them except of some special cases where their usage is justified.

More precisely, IMHO usage of header-only libs is justified only the lib cannot be moved into a shared library without defeating its purpose. Such libs purpose is usually pregeneration and precomputation, by the means of abusing compiler machinery (templates, constexprs and inlining), for performance optimization (and this often gives one of the fastest libs for such a purpose, at a cost of impossibility to modify behavior in runtime) usually, such as:

• compile-time hashing
• compile-time finite automata generation
• compile-time compilation of a simple parser (the result when aggressive compiler optimizations are enabled is close to a sequence of CPU instructions describing a parser for a specific use case, while in source code it is described at high level)

CLI11 sources don't look like it is such a library.

So it may make sense to allow it be used as a shared library. Under "using as a shared library" I mean that the library is optimized for that and the headers are purportedly designed to minimize the amount of code in them and maximize the reusability of the code within the corresponding shared library.

This would allow to remove duplications between different applications and libraries and speed-up compilation of applications. Of course it can cause "shared library hell", but there are already widely used approaches eliminating it, such as building software for a distro and shipping it as a package for that distro, declaring some API as stable, versioning of API within a single lib and putting different incompatible versions of libs into different packages. In other words, "shared library hell" is not a big issue.

So, it is proposed

1. Split the code into hpp and cpp files
2. Introduce a macrodef that would enable inclusion of content of cpp files into headers
3. For a shared lib flavour ship only headers and set the macrodef into disabled state in the config
4. For a header-only lib flavour set the macrodef enabled and include the cpp files into the package alongside to the headers.

[henryiii]

This was first discussed in #194, was originally targeted for 2.0 (and is the reason the MakeSingleHeader.py script was rewritten in 2.0), but I didn't have time to implement it and we went ahead with the 2.0 release. The same thing is also planned for pybind11, as well. You are very correct in that CLI11 has had this in mind for a very long time, and has mostly avoided anything too "header-only".

Are you interested in helping with this? The one extra requirement is the single header file mode also needs to still work, but MakeSingleHeader.py should now be flexible enough to handle that.

[henryiii]

Please look at the proposal in #338 and see if it looks like what you were thinking.