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>