Re: Broken implicit DEPENDS?

[Jonathan Perkin <jperkin%mnx.io@localhost>]

* On 2023-11-21 at 23:55 GMT, Joerg Sonnenberger wrote:

> Exhibit B: audio/libmp3splt. This one is a bit cleverer than it should be, but
> kind of highlights the problem seen in a couple of other places. If this
> package is b3ed and the libvorbis is also desired explicitly, any using
> package needs to override the value again. That is broken and requires
> some fixing.  I think the correct way to address this requires a change
> to the b3 logic. We should be pushing a "build-time only" marker on the
> stack and handle the rest in the central logic, i.e. a package is considered
> build-only if (1) DEPMETHOD is set to build or (2) all indirect includes are
> with a "build-time only" marker on the stack.

One of the other fundamental problems are the include guards in every 
single buildlink3.mk file.  Take the harfbuzz failure as an example:

 * First it includes gtk-doc in options.mk.

 * gtk-doc's bl3 sets DEPMETHOD=build, and includes glib2's bl3.

 * This means, at least after my change, that glib2 and all its 
   dependencies are tagged as build.  This is correct so far (at least 
   in terms of bl3 logic, I don't know if gtk-doc is correct here).

 * harfbuzz then includes glib2 itself at the top-level.  Again, my 
   changed logic means this is now tagged as a full dependency.  All 
   good so far.

Except!  Because of buildlink3 include guards, all of the dependencies 
in glib2's buildlink3.mk are never included again, and so they cannot be 
set to full dependencies, are left as "build" due to gtk-doc, and the 
later checks fail.

I don't currently have any good ideas for fixing this :/

--
Jonathan Perkin   -   mnx.io   -   pkgsrc.smartos.org
Open Source Complete Cloud   www.tritondatacenter.com