I know that llvm uses separate xtoolchain ports, but those depend on the stock llvm. In this case we are already patching GCC to be a system compiler, so I wonder if it might not be better to fold the xtoolchain bits into the freebsd6-gcc port itself and just have <arch>-gcc6 install the toolchain file. Then it's kind of nice because to get cross toolchain "foo" (e.g. mips-gcc6) you 'pkg install mips-gcc6'.

We could perhaps collapse the devel/<arch>-binutils ports into a single devel/freebsd-binutils that used FLAVORS, but that would still be a slave of devel/binutils, so not sure how that would actually work? Might be simplest to just let them be for now?

Also, if this approach works, I'd probably like to do something similar with base/gcc where it becomes base/gcc6 and we have a base/gcc9, etc.

I have always hated the fact that the masterport was (for hysterical raisins?) powerpc64. Thanks for attempt to undo that mess.

I'll give it a shot here locally (with the X86 string) and see what happens.

I can confirm that these all build on my test box.

w/rt the 'I386' string, we seem to have an incompatibility between src and ports. I don't think it's worth holding up progress to look into it.

In D22147#484948, @linimon wrote:

I can confirm that these all build on my test box.

w/rt the 'I386' string, we seem to have an incompatibility between src and ports. I don't think it's worth holding up progress to look into it.

Do you have any thoughts on merging the xtoolchain package into the freebsd6-gcc package (per my first comment)?

@brooks suggested he would consider merging the llvm-xtoolchain ports into the llvm ports as well. I think it is nice that you can 'pkg install <foo>' to get the bits for 'make CROSS_TOOLCHAIN=<foo>'

In D22147#486621, @imp wrote:

Nothing caught my eye, though the PLIST is getting to be rather long and a bit of a PITA to deal with :(

What I would really like is to have a shared pkg-plist and separate pkg-plist.${TARGETARCH} files. There doesn't seem to be an easy way to do this currently.

In D22147#486624, @jhb wrote:

@brooks suggested he would consider merging the llvm-xtoolchain ports into the llvm ports as well. I think it is nice that you can 'pkg install <foo>' to get the bits for 'make CROSS_TOOLCHAIN=<foo>'

I'm happy to do this, but I do like to batch changes to llvm ports other than llvm-devel so I'll probably queue the change for inclusion with other updates (e.g. patches for riscv support.)

In D22147#486635, @jhb wrote:

In D22147#486621, @imp wrote:

Nothing caught my eye, though the PLIST is getting to be rather long and a bit of a PITA to deal with :(

What I would really like is to have a shared pkg-plist and separate pkg-plist.${TARGETARCH} files. There doesn't seem to be an easy way to do this currently.

The thing you could do now would be to use PLIST_FILES either directly in a Makefile or with a != assignment that pulled them out of some pkg-plist.${ARCH}. I do the former for sanitizer runtimes in the llvm ports. It's ugly, but works.

I think all you have to do to support multiple files in PLIST would be one of the following in the generate-plist target in bsd.port.mk:

• Remove the '-f' check and if a port lists a non-existent file in PLIST, let sed fail with an error. Note that sed will already work fine with multiple files given on the command line where PLIST is already used.
• Use a .for around the -f check and sed invocation.

Both of these seem pretty small. I suspect the -f check is required so ports that use PLIST_FILES or PLIST_DIRS don't have to explicitly set an empty PLIST, so probably the latter approach is best.

Any further thoughts? I could perhaps work on the PLIST thing as a followup and then split up the plist after that

In D22147#489200, @brooks wrote:

I think this is ready to go as is. PLIST cleanups can wait IMO.

yea, my comments in this area were based on a flawed understanding of things...

A pre-commit hook says I can't commit anything using FLAVORS without portmgr approval, so adding portmgr.