Re: RFC: distbb for cross-compiling packages

[Aleksey Cheusov <cheusov%tut.by@localhost>]

 >> PKGNAME:        xdm-1.1.11
 >> PKGPATH:        x11/xdm
 >> BUILD_DEPENDS:  checkperms>=1.1:../../sysutils/checkperms
 >>                 libtool-base>=2.2.6bnb3:../../devel/libtool-base
 >>                 pkg-config>=0.19:../../devel/pkg-config
 >> TARGET_BUILD_DEPENDS:inputproto>=1.4:../../x11/inputproto
 >>                 kbproto>=1.0.2:../../x11/kbproto
 >>                 renderproto>=0.9.3nb1:../../x11/renderproto
 >>                 renderproto>=0.9:../../x11/renderproto
 >>                 xcb-proto>=1.4:../../x11/xcb-proto
 >>                 xextproto>=7.0:../../x11/xextproto
 >>                 xineramaproto>=1.1.1:../../x11/xineramaproto
 >>                 xproto>=7.0.9:../../x11/xproto

> That makes perfect sense.

> My only remaining point is that I think it should be

> BUILDHOST_BUILD_DEPENDS and (implicitly target) BUILD_DEPENDS
We can easily add BUILDHOST_BUILD_DEPENDS and TARGET(HOST)_BUILD_DEPENDS
variables in order to avoid confusions with BUILD_DEPENDS.
But renaming BUILD_DEPENDS to something else in all packages and all
files under mk/ was not in my plan.
What I tried to do with my patch is to make it as small and simple as
possible.

I'm not opposed to your proposal but I don't feel myself good enough to
work with mk/. Also note that making BUILD_DEPENDS target platform
dependency requires rewriting the documentation and breaks backward
compatibility. Two new variables BUILDHOST_BUILD_DEPENDS and
TARGETHOST_BUILD_DEPENDS looks reasonable alternative to me.

> instead, because "a depends on b" is naturally about target dependencies
> and exceptional when it's a build tool.   In the NetBSD base system, we
> have nbfoo for the build-host tools, and regular dependencies in
> makefiles for the target dependencies.

> And, I still don't understand why *proto above isn't bl3 instead of
> *_BUILD_DEPENDS.
I'm not sure I understand your question.
*proto dependencies comes from bl3 framework.

 >> 0 0 xdm>make /tmp/obj-pkgsrc/x11/xdm/work/.depends
 >>
 >> 0 xdm>cat /tmp/obj-pkgsrc/x11/xdm/work/.depends
 >> bootstrap       digest>=20010302        ../../pkgtools/digest
 >> build   kbproto>=1.0.2  ../../x11/kbproto
 >> build   xproto>=7.0.9   ../../x11/xproto
 >> build   xcb-proto>=1.4  ../../x11/xcb-proto
 >> build   xextproto>=7.0  ../../x11/xextproto
 >> build   inputproto>=1.4 ../../x11/inputproto
 >> build   renderproto>=0.9.3nb1   ../../x11/renderproto
 >> build   xineramaproto>=1.1.1    ../../x11/xineramaproto
 >> full    sessreg-[0-9]*  ../../x11/sessreg
 >> full    libXaw>=1.0.5   ../../x11/libXaw
 >> full    libXmu>=1.0.0   ../../x11/libXmu
 >> full    libXft>=2.1.14nb1       ../../x11/libXft
 >> full    libXinerama>=1.0.1      ../../x11/libXinerama
 >> 0 xdm>

> So that makes sense, to have them listed as build there, where that
> implies target packages.

> Presumably USE_TOOLS causes a different kind of dependency, where the
> tools have to be installed on the build host, but it's not a dependency
> of the package at all.

Absolutely.

 >> Result:
 >>   - BUILD_DEPENDS contains only build host dependencies

> It's still my view that these are bugs that should be in USE_TOOLS,
> similar to how when we need a utility in the base system we either
> depend on the native one or add a new nbfoo.

Have a look at textproc/dict-mueller7 package.
We cannot make perl modules and rarely used utils like dictfmt(1),
dictzip(1) and GNU fmt(1) a part of USE_TOOLS. And I don't see reason for this.
It's easier to keep BUILD_DEPENDS as is IMHO.

 >>   - TARGET_BUILD_DEPENDS contains target dependencies only (headers).
 >>   - "depends" target doesn't require build host packages (checkperms,
 >>     libtool-base and pkg-config) anymore.

> I agree that this is the right behavior (and just differ on naming).

> So, what do you and others think about the notion that any use of
> BUILD_DEPENDS is (almost) intrinsicially a bug, and should be replaced
> by bl3 (for target dependencies) or USE_TOOLS.
See above about rarely used tools. It is impractical to add all of them
to USE_TOOLS.

> Actually, I'll go farther and say that BUILD_DEPENDS as a target
> dependency that isn't reasonably expressed as bl3 on packages containing
> headers or the functional equivalent also is a bug.
See above. Packages that provide headers and static libraries comes from
bl3 internals and most often are activated using bl3.

> In particular, the use of BUILD_DEPENDS to list perl packages that are
> needed to run tests seems fishy.
TEST_DEPENDS was discussed some time ago but I don't remember what
was the result of that discussion. IIRC asau@ participated in it.

-- 
Best regards, Aleksey Cheusov.