Re: Summary of implicit DEPENDS problem

[Greg Troxel <gdt%lexort.com@localhost>]

Jonathan Perkin <jperkin%mnx.io@localhost> writes:

I am only commenting on two bits; the rest makes sense to me.

>  * Problem 3: buildlink3.mk inclusion guards
>
>    gtk-doc's buildlink3.mk explicitly sets DEPMETHOD=build, which is
>    reasonable as it's only ever used at build time.  It in turn includes
>    glib2, which is then tagged as "build" too.
>
>    Later, harfbuzz also directly includes glib2 as it is required as a full
>    dependency.  However, because of the buildlink3 inclusion guards, while
>    glib2 will now correctly be set to "full" (because that's the default for
>    top-level inclusions), none of its .includes will be re-parsed and also
>    tagged as "full".  You can see that clearly in the "show-buildlink3"
>    output as the second "glib2" never descends into its dependencies again.

It strikes me that inclusion guards could check;

  has this been included before, with at least this value of DEPMETHOD

so that including it once with build and once with full would do the
processing the second time.

That might require some fixes, but conceptually it seems like the right
thing.

>    This is why my hacky fix for now is to include glib2 prior to gtk-doc,
>    so that glib2 and all its dependencies are correctly logged as "full",
>    before including gtk-doc as "build".

Sure, that's a sensible workaround.

>    I don't know how to fix this without a radical overhaul of buildlink3.mk
>    files.  Joerg suggested including additional metadata in BUILDLINK_TREE
>    identifiers, but I still don't see how this gets around the inclusion
>    guard problem.

Did Joerg mean essentially what I'm proposing?

>   * Adds IMPLICIT_DEPENDS and IMPLICIT_BUILD_DEPENDS, ensuring that the
>     depends file includes them too.

I don't quite follow this from your email.  It sounds like
IMPLICIT_DEPENDS is something that is a full dep of something that is a
full dep, and IMPLICIT_BUILD_DEPENDS is a full dep of something that is
a build dep.  Things that are build deps only of either are not
relevant.  Is that what you mean?  (I'm not at all sure I got that
right.)

> As per the commit message, this isn't ready for integrating into
> pkgsrc yet though.  Due to problem #3 we see occasional false
> positives if an indirect dependency is tagged as "build" when it is
> later correctly tagged as "full".

So check-shlib will complain, even though things are written in a way
that should be ok.  But they aren't actually ok due to #3?

> I'm happy to keep this in my tree for now and commit workarounds as I
> find them, as I don't think other folks would be happy with any false
> positives.

Is it sensible to think about integrating with a flag to enable, so
people who want to stmuble over these things and fix/add-workaround can?

Or do we think that misordering depends from what feels natural as a
workaround is icky, and we should refrain from doing that and instead
fix the inclusion guard bug?