On 06.03.20 23:42, Vinnie Falco via Boost wrote:
I think Peter is right in this case. Library A which uses library B should not have an opinion on whether library B is consumed as header-only or as a linked library. The decision on how each library in a linked executable is configured should be up to the top-level build target (i.e. the program) and not any of the individual components. This is why the default for libraries which have a header-only configuration, should be a linkable library target, since it creates the least headache.
Wait, what? Linkable are a huge headache to me, to the point where I'll seriously consider rewriting a third-party linkable library to be header-only just to avoid having to link to them. Problems with linkable libraries include: - I have to compile them, which means either messing with their native build system, trying to get it to build on all of my platforms using all of my cross-compile toolchains, or replacing their native build system with my own. The latter is often easier than the former. - If the library has linkable libraries as dependencies, I get to do the same thing for them, recursively. - I have to make sure that I'm linking to the correct version of these libraries, i.e. not the system-wide installed versions. - If I need to compile multiple copies of a library with different options, I get a combinatorial explosion of different libraries. My library build matrix is full of red entries where I haven't been able a particular library in a particular configuration that I need. The green entries are often the result of days of work. On the other hand, I've never had any trouble with header-only libraries. -- Rainer Deyke (rainerd@eldwood.com)