buildlink3.mk for tools

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

How can a package run clang at build-time as a tool?

Currently the answer appears to be that it should use

.include "../../lang/clang/buildlink3.mk"

which sets BUILDLINK_FILES.clang to populate ${BUILDLINK_DIR}/bin with
executables like clang and clang++, and since ${BUILDLINK_DIR}/bin is
put in PREPEND_PATH during the build, the build process can run
`clang' to get at the intended executable.

We have various other similar buildlink3.mk files that populate
${BUILDINK_DIR}/bin with symlinks to the dependency's installed files,
e.g. in lang/llvm and archivers/libzip.


But this doesn't make sense for cross-compilation.  Say you're
cross-compiling www/firefox on an x86 machine with the configuration:

LOCALBASE=		/home/user/pkg
CROSS_DESTDIR=		/home/user/destdir.powerpc
CROSS_LOCALBASE=	/usr/pkg

In other words, you're doing an unprivileged build in your home
directory on your x86 machine, to build packages that will go in
/usr/pkg on a powerpc system.

During the www/firefox cross-build, it will see these variables:

TOOLBASE=		/home/user/pkg
CROSS_DESTDIR=		/home/user/destdir.powerpc
PREFIX=			/usr/pkg

By using clang's buildlink3.mk it will pull in BUILD_DEPENDS+=clang,
and BUILDLINK_DIR will be populated so that bin/clang is a symlink to:

/home/user/destdir.powerpc/usr/pkg/bin/clang

That doesn't make sense as a tool -- it's a powerpc executable.

Instead, we need to pull in TOOL_DEPENDS+=clang and find the clang
executable to run at build-time at:

/home/user/pkg/bin/clang

(And we needn't build clang as a powerpc executable at all, anywhere
in this process.)


I think what we should do -- for this case and many other cases -- is
have www/firefox include a file like this instead of buildlink3.mk:

# lang/clang/tool.mk
.if !defined(CLANG_TOOL_MK)
CLANG_TOOL_MK=		# defined

TOOL_DEPENDS+=		clang>=18.0.0:../../lang/clang

TOOLS_CREATE+=		clang
TOOLS_PATH.clang=	${TOOLBASE}/bin/clang

.endif

And I suspect anything that uses `BUILDLINK_FILES.<pkg>+= bin/...'
will need similar treatment.  Here's an arbitrary sampling of cases I
suspect are similar:

archivers/libzip/buildlink3.mk:BUILDLINK_FILES.libzip+= bin/zipcmp
devel/capnproto/buildlink3.mk:BUILDLINK_FILES.capnproto+=       bin/capnp
graphics/openjpeg/buildlink3.mk:BUILDLINK_FILES.openjpeg+=      bin/opj_compresslang/llvm/buildlink3.mk:BUILDLINK_FILES.llvm+=          bin/llvm-as
net/grpc/buildlink3.mk:BUILDLINK_FILES.grpc+=   bin/grpc_python_plugin
x11/qt5-qtbase/buildlink3.mk:BUILDLINK_FILES.qt5-qtbase+=       qt5/bin/qmake

Unfortunately, not _all_ `BUILDLINK_FILES.<pkg>+= bin/...' need this
treatment.  For example:

devel/apr/buildlink3.mk:BUILDLINK_FILES.apr+=   bin/apr-1-config

In this case, apr-1-config is a shell script that is executed at
build-time to describe how to link against the package as it will
exist at run-time -- like pkg-config.  This script has paths like
PREFIX=/usr/pkg baked into it.  If you used TOOL_DEPENDS here, it
would be wrong -- it would use /home/user/pkg instead, giving the
wrong rpaths for programs that are supposed to be linked against the
apr in /usr/pkg on the powerpc system.

So we can't uniformly transform all BUILDLINK_FILES under bin/ to
TOOL_DEPENDS and TOOLS_CREATE.  It needs case-by-case analysis.


Any thoughts before I start drafting patches for this approach?