Re: Header-only libraries linking to compiled libraries...

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2021-11-02 23:08:02

On 11/3/21 01:45, Peter Dimov via Boost wrote:
> 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.

If you make a library, and generate a CMake target for it, that library
will be linked in user's project, however dummy it is. This means the
library has to be packaged, and the package will be a dependency for
downstream packages.

No, just no. The library is header-only, let's keep it that way instead
of creating a crutch for a build system.

>> 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.

Agreed, we do need two separate knobs.

> (This is not going to help GCC users on Windows, assuming we care about them.)

We do care about gcc (well, I do), and auto-linking would be an
intermediate workaround, e.g. for 1.78, until we come up with a proper
solution. This would be something better than what we had before.