|
Boost : |
From: Gavin Lambert (boost_at_[hidden])
Date: 2023-03-15 00:31:03
On 15/03/2023 06:35, Robert Ramey wrote:
> Right. This is a built-in deficiency of the package manager approach.
> Dependencies are dependent upon the actual end user application and
> cannot be logically discerned a priori by any package manager. Contrary
> to what one would hope, the package manager is not a panacia and trying
> to make it into one is a hopeless quest which leads to pointless efforts
> to "eliminate dependencias" and create "standalone" libraries.
What I imagine is part of the problem is that the package management
ecosystem has grown up independently from the component authors -- so
the package maintainer runs tools to see "oh, this header file is
included, that must be a dependency" because they're less familiar with
the *context* of that inclusion than the actual component author, and
there aren't even standardized package names let alone a standardized
way for the component author to indicate to package tools what things
should be considered required vs. optional.
There are occasional whispers of something almost like that, in the form
of autoconf, pkg-config, or CMakeFiles that can list dependencies, but
these aren't universal and can have complex logic based on options. And
then there's distinctions between dev and runtime dependencies...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk