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