|
Boost : |
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2024-04-28 16:51:36
On 4/28/24 18:53, Artyom Beilis via Boost wrote:
> 1st of all it is Windows specific, it does not apply to any other builds -
> so I still need to make build properly via cmake or other tools
True. But given that it is a Windows-only feature, it is popular among
the Windows-only users. If a user is building his project only on
Windows, e.g. in a Visual Studio project, he probably doesn't care about
our build system - CMake or b2 - beyond building Boost, of course, and
may rightfully rely on auto-linking to pull the right Boost libraries
and their respective dependencies. In a sense, the auto-linking is a
substitute for the dependency tracking feature of a build system.
The problems begin when auto-linking doesn't work, or disabled, as was
proposed by Rene. Suddenly, the user now needs to manually figure out
all the dependencies himself, and specify those in his project. This may
be a non-trivial task, as usually this is not documented, and the user
has to parse through source code or go through trial and error.
I vaguely remember that auto-linking didn't work in some cases (I think
it was related to static libraries, but I may be mistaken). That's why I
asked what the problem was.
> 2nd creates unobvious dependencies that you may not expect
This is not really a problem, or rather not more of a problem than with
a common build system such as CMake. If you use a library and link with
it, you accept whatever dependencies it brings, and you don't want to
track these dependencies yourself. If you do care about dependencies,
you will have to inspect them either way.
> 3rd it problematic for libraries that not always require linking (or only
> partial functionality requires linking), especially when 1 library uses
> another
Again, not really different from CMake or b2. If you link with a shared
library, you get all its dependencies regardless of the part of it you
are using. If you link with a static library, you only link with what
you use (on TU granularity).
> 4th back ago I experienced different failures or incorrect naming - don't
> recall why (non-standard build?)
This sounds like a configuration mismatch that was (luckily) caught as a
side product of auto-linking.
Personally, I'm neutral to this feature as I'm not using Windows. But my
understanding is that this feature is still popular among Windows users,
so us disabling or removing it will probably result in lots of complaints.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk