On Thu, 21 Aug 2003, Julio M. Merino Vidal wrote:

: > But fixing (2) is much more painful.  This will require splitting out the
: > DEPENDS part of each buildlink2.mk file somehow (via a new .mk file and/or a
: > make variable), so that other buildlink2.mk files can choose not to
: > propagate inner dependencies.  Manual inspection will then be required to
: > add these splits where appropriate; typically where one utility shlib has an
: > inner dependency on another utility shlib, but an application using the
: > first one doesn't care or know about the second.  For instance, GTK, SDL,
: > etc. abstract away their underlying implementation layers, so apps using
: > them don't give a damn about their dependencies.
:
: This is why I proposed it now.  The switch to buildlink3 will require manual
: inspection of packages too, and if the solution is present into it from now,
: both things can be done at once.

Fine with me, but remember that pkg/21097 is a prerequisite for the above.
If DEPENDS still registers recursively (which, as I've noted, should be
removable), you'll be masked from most of the bad side effects necessary to
know what buildlink recursions should *not* be split apart.

(There's another thread whose title escapes me where I defined this in
detail.  In short:  If app A has to have -lB to link and that pulls in -lC
indirectly, no recursion is needed, because it only cares about the ABI of
libB.  If app A needs -lB -lC to link and/or needs the headers of libC to
compile, it needs to have DEPENDS registered for *both* because it's ABI
dependent on both.)

-- 
-- Todd Vierling <tv@pobox.com>