llvm-*: Move LLVM_BINUTILS toosl to toolchain package

[emaste]

Summary

Some of the LLVM binary utilities were included in the Clang package
(because they did not set an explicit PACKAGE).  Add where missing,
and move the setting under MK_LLVM_BINUTILS.

With LLVM_BINUTILS (default) these tools are included in the toolchain
package, including a link without the llvm- prefix.  When LLVM_BINUTILS
is disabled only the llvm-prefixed versions are included, in the clang
package.

PR:             293610

[emaste]

Fix up llvm-cxxfilt

[ivy]

With LLVM_BINUTILS (default) these tools are included in the toolchain
package, including a link without the llvm- prefix. When LLVM_BINUTILS
is disabled only the llvm-prefixed versions are included, in the clang
package.

i'm not sure if i like this; it seems odd that the same binary can move between packages like that. is the rationale here to avoid bringing in LLVM libraries as a dependency of toolchain when LLVM_BINUTILS is disabled?

[ivy]

one way i think this could cause problems is once we add pkgbase depends support to ports. say there's a port that specifically requires "llvm-objcopy", which package should it depend on to get that?

[emaste]

i'm not sure if i like this; it seems odd that the same binary can move between packages like that. is the rationale here to avoid bringing in LLVM libraries as a dependency of toolchain when LLVM_BINUTILS is disabled?

Yeah, I can see arguments either way.

My thinking is the toolchain package ought to offer the standard binutils-like tools (needed if you were using a different compiler, say). With the current approach it seems odd to me that setting LLVM_BINUTILS=no results in a toolchain package that includes ELF Tool Chain's objcopy and also llvm-objcopy and has a dependency on llvm libraries.

[emaste]

one way i think this could cause problems is once we add pkgbase depends support to ports. say there's a port that specifically requires "llvm-objcopy", which package should it depend on to get that?

Arguably the correct way to handle this would be for llvm-objcopy to be in a Clang (or LLVM) package, and objcopy to be in the toolchain package. It's currently a hard link though and would have to become a symlink instead.

[emaste]

Right now c++filt, objcopy, readelf, addr2line are either in the clang or toolchain package, depending on LLVM_BINUTILS.

[ivy]

In D55692#1274515, @emaste wrote:

Arguably the correct way to handle this would be for llvm-objcopy to be in a Clang (or LLVM) package, and objcopy to be in the toolchain package. It's currently a hard link though and would have to become a symlink instead.

i think this would be my preferred solution (although i'm open to other arguments): it puts everything in its rightful place, and the symlink + dependency in the LLVM_BINUTILS case makes it semantically clear that e.g. objcopy is llvm-objcopy. i know we've historically preferred hard links here, but they don't play nicely with pkg in general, and i'm not sure the reasoning for that is still relevant (e.g., saving inodes, which hardly matters in 2026).

this would require a conditional dependency from toolchain to clang, which we don't currently support. i don't mind adding support for that though, i think it's useful in general.

what do you think?

[emaste]

what do you think?

Originally I thought it would be excessive, but upon a little more thought I think it makes sense. I opened D55693 to switch to symlinks.

We'll have to sort out the conditional dependency, and we'll also need to split these Makefiles. I can look at the second part.

[emaste]

As discussed w/ @ivy, I think the better path is to:

1. Move the unprefixed links to SYMLINKS
2. Move the unprefixed symlinks into their own Makefile with PACKAGE=toolchain (prefixed tools will move back to the clang package).
3. Add a conditional dependency to the toolchain package on clang

[emaste]

Make a new usr.bin/clang/toolchain/Makefile to put the LLVM binutils symlinks in the toolchain package when LLVM_BINUTILS is set.

[ivy]

i decided that, rather than waste time adding more features to the current package build, i'd do the subdir-based rewrite that i've been planning for a while. that means you will be able to do something like this in packages/toolchain/Makefile:

.include <src.opts.mk>

.if ${MK_LLVM_BINUTILS} != "no"
PKG_DEPS.toolchain+= llvm
.endif

this should be ready for review in a couple of days.

[ivy]

In D55692#1277265, @ivy wrote:

this should be ready for review in a couple of days.

D56087

[emaste]

Rebase, add Makefile.inc1 change to build it during bootstrap

[bapt]

looks good to me

[brooks]

usr.bin/clang/Makefile

25

What ensures that the manpages have been installed when toolchain is entered and tries to create hard links?

[ivy]

D56087 has now landed, so if you want to rebase, i can review this again.

[emaste]

rebase, address comments from ivy (dep on llvm) and brooks (subdir .WAIT)

[ivy]

one nit, but otherwise this looks good. i assume you tested the package build both ways, if not, please do before landing :-)

packages/toolchain/Makefile

9

[brooks]

usr.bin/clang/Makefile

25

This feels a little blunt, but SUBDIR_DEPEND_toolchain=<list of appropriate dependencies> probably isn't better?

[emaste]

usr.bin/clang/Makefile

25

My thought was the toolchain package will have a minuscule build time as it does not actually build anything, although I didn't consider that it will also serialize other subdirs (like lld), so perhaps should have the messy list.

[emaste]

usr.bin/clang/Makefile

25

Maybe:

_LLVM_BINUTILS=         llvm-ar
_LLVM_BINUTILS+=        llvm-ar
_LLVM_BINUTILS+=        llvm-cxxfilt
_LLVM_BINUTILS+=        llvm-nm
_LLVM_BINUTILS+=        llvm-objcopy
_LLVM_BINUTILS+=        llvm-objdump
_LLVM_BINUTILS+=        llvm-readobj
_LLVM_BINUTILS+=        llvm-size
_LLVM_BINUTILS+=        llvm-strings
_LLVM_BINUTILS+=        llvm-symbolizer

SUBDIR+=        ${_LLVM_BINUTILS}

SUBDIR+=        toolchain
SUBDIR_DEPEND_toolchain= ${_LLVM_BINUTILS}