Andrey Semashev wrote:
As I said in the Boost.UUID bug, I'm opposed to dummy compiled libraries where there shouldn't be one in the first place. Header-only libraries need to stay header-only, as in some cases this makes a difference between a library being used or not.
Header-only libraries would still be header-only. Having a dummy compiled library doesn't magically turn a library into a non-header-only one.
As I also suggested in the bug, the problem needs to be solved in CMake and headers. Two immediate workarounds (besides reusing CMakeLists.txt, if possible) I see are:
- Stop defining BOOST_ALL_NO_LIB in CMake config.
I'm not in support of this. Autolinking to Boost libraries when using a proper build system causes nothing but trouble. It does occasionally help hide problems (such as the project not linking to the right target), but that's not worth it. b2 defines BOOST_ALL_NO_LIB for the same reason.
- Ignore BOOST_ALL_NO_LIB (and library-specific equivalents) for linking non- Boost libraries.
We've been over this more than once, and we haven't gotten anywhere. IMO, this option should never have applied to autolinking system libraries, and it used not to, but then users who wanted to disable autolinking completely complained. There needs to be a way to enable or disable autolinking to Boost libraries separately from non-Boost ones. (This is not going to help GCC users on Windows, assuming we care about them.)