Re: Reducing dependency on Boost.Regex

From: Boris Kolpackov (boris_at_[hidden])
Date: 2023-03-15 10:55:02

Robert Ramey via Boost <boost_at_[hidden]> writes:

> On 3/13/23 5:54 AM, Boris Kolpackov via Boost wrote:
>
> > This implicit "if you don't include the header then you don't need to
> > link the dependency" approach doesn't scale well to cases where Boost is
> > split into individual packages which are managed by a package manager.
> 
> 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.

They cannot be "magically" discerned but there can be a mechanism for
specifying them explicitly.

I don't believe we are disagreeing about the fundamental issues, which
is that there needs to be support for optional dependencies. The
difference is that you seem to advocate implicit discovery (and
ongoing maintenance) of optional dependencies by the end-user (based
on linker errors, by carefully studying the documentation, etc) while
I advocate having an explicit mechanism in the package manager for
the library author to specify which functionality is optional (and
that requires optional dependencies) and for the library user to
request this optional functionality (and automatically get the
required dependencies). We have such a mechanism in build2, in our
experience it works well, and we have applied it to the Boost
libraries.

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

That's quite a bizarre perspective, seeing that the main functionality
of a package manager is to make management of dependencies easier. It
also doesn't match empirical evidence. For example, in Rust it's hard to
find a package that doesn't have at least a few dozens dependencies (and
more often a few hundreds). If anything, the problem is actually the
opposite.