Subject: twisty buildlink2.mk's
To: None <tech-pkg@netbsd.org>
From: Todd Vierling <tv@pobox.com>
List: tech-pkg
Date: 06/01/2003 13:45:07
Okay, people, could we please stop making every buildlink2.mk include all
the same buildlink2.mk's that are already in each package's Makefile?  For
one example, see PR pkg/21747, but I'm seeing these all over the place now
that I'm digging.

What should be the layout in almost all cases is something like the
following:

foo/pkg1/buildlink2.mk: DEPENDS+= pkg1-[0-9]*:../../foo/pkg1
foo/pkg2/Makefile:      .include "foo/pkg1/buildlink2.mk"
foo/pkg2/buildlink2.mk: DEPENDS+= pkg2-[0-9]*:../../foo/pkg2
foo/pkg3/Makefile:      .include "foo/pkg2/buildlink2.mk"

But these days, I'm seeing a boatload of:

foo/pkg2/buildlink2.mk: .include "foo/pkg1/buildlink2.mk"

...which, in most cases, is wrong--because dependencies of pkg2 don't give a
damn about pkg1, and the dependency comes in anyway as part of
"DEPENDS+=pkg2".  (If pkg3 cares about pkg1, then pkg3 should be including
pkg1/buildlink2.mk itself!)

Where this is seriously hosing is when I'm trying to add or remove a single
deep-level dependency because my setup doesn't need it.  I have to go about
removing it from both the package's Makefile *and* its buildlink2.mk -- even
though nothing at the top level of the dependency tree cares about this deep
level dependency.

When using my change not to register recursive package dependencies (see
PRs; this will supposedly be brought into pkgsrc at some point), this also
means recompiling everything that included that mid-level buildlink2.mk,
where it would not be necessary otherwise.  That's just bogus, because the
recompiled binaries of the top-level dependent package are identical to
those before the change.

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