One copy to make CPUARCH from ARCH.

[imp]

Summary

Consolidate all the regular expressions to convert from MACHINE_ARCH
to MACHINE_CPUARCH into a variable and use that variable in preference
to the almost identical copies in the tree (which should have been
identical).

[imp]

Makefile

253

I'm surprised, but this doesn't require a new sys.mk installed to work.

[emaste]

Seems reasonable

[andrew]

share/mk/sys.mk

16

After this we should remove the hf from the arm case.

[imp]

share/mk/sys.mk

16

But of course. I've just added this to my branch as a separate commit.
And soon add v7, eh?

[bdrewery]

I did something like this before and ran into a bug and reverted it. Hang on, looking it up.

[bdrewery]

My initial attempts were rS302670 and rS302671 but I reverted it in rS302690 with reasoning:

MACHINE_CPUARCH smells like MACHINE except for arm64/aarch64 which
has it backwards.

[bdrewery]

Makefile

253

Nope, make reads share/mk/sys.mk.
Note the code you replaced has :C/aarch64/arm64/, but your sys.mk version does not have that.

share/mk/sys.mk

16

Here's what I used before which was a bit simpler to understand (may not be up-to-date)

-MACHINE_CPUARCH=${MACHINE_ARCH:C/mips(n32|64)?(el)?/mips/:C/arm(v6)?(eb|hf)?/arm/:C/powerpc64/powerpc/:C/riscv64/riscv/}
+MACHINE_CPUARCH_SUB= \
+               C/mips(n32|64)?(el)?/mips/ \
+               C/arm(v6)?(eb|hf)?/arm/ \
+               C/aarch64/arm64/ \
+               C/powerpc64/powerpc/ \
+               C/riscv64/riscv/
+MACHINE_CPUARCH=${MACHINE_ARCH:${MACHINE_CPUARCH_SUB:ts:}}

This pattern requires using :ts everywhere your __TO_CPUARCH is used.

[bdrewery]

In D11986#248631, @bdrewery wrote:

My initial attempts were rS302670 and rS302671 but I reverted it in rS302690 with reasoning:

MACHINE_CPUARCH smells like MACHINE except for arm64/aarch64 which
has it backwards.

Please see these for my reason for revert and reasoning on the above statement:
https://lists.freebsd.org/pipermail/svn-src-all/2016-July/127165.html
https://lists.freebsd.org/pipermail/svn-src-all/2016-July/127166.html

[imp]

In D11986#248631, @bdrewery wrote:

My initial attempts were rS302670 and rS302671 but I reverted it in rS302690 with reasoning:

MACHINE_CPUARCH smells like MACHINE except for arm64/aarch64 which
has it backwards.

This reasoning is sadly wrong. MACHINE_CPUARCH has nothing to do with MACHINE. The former is a userland construct while the latter is a kernel construct. The names are only accidentally related.

[bdrewery]

In D11986#248646, @imp wrote:

In D11986#248631, @bdrewery wrote:

My initial attempts were rS302670 and rS302671 but I reverted it in rS302690 with reasoning:

MACHINE_CPUARCH smells like MACHINE except for arm64/aarch64 which
has it backwards.

This reasoning is sadly wrong. MACHINE_CPUARCH has nothing to do with MACHINE. The former is a userland construct while the latter is a kernel construct. The names are only accidentally related.

Ok, so perhaps only my change rS302671 was the problem and the original commit in rS302670 was fine.

[imp]

In D11986#248636, @bdrewery wrote:

In D11986#248631, @bdrewery wrote:

My initial attempts were rS302670 and rS302671 but I reverted it in rS302690 with reasoning:

MACHINE_CPUARCH smells like MACHINE except for arm64/aarch64 which
has it backwards.

Please see these for my reason for revert and reasoning on the above statement:
https://lists.freebsd.org/pipermail/svn-src-all/2016-July/127165.html
https://lists.freebsd.org/pipermail/svn-src-all/2016-July/127166.html

Your reasoning here is wrong, so your conclusions are as well. You reasoned it should be MACHINE/TAGET sometimes, but that's not ever correct except accidentally.

MACHINE == TARGET, always
MACHINE_ARCH == TARGET_ARCH always
MACHINE_CPUARCH is the directory we store all the files that implement MACHINE_ARCH functionality, so it's unrelated to MACHINE/TARGET, which store the files

This separation is on purpose. The aarch64 vs arm64 is an unfortunate accident and breaks the historical pattern due to the desire to match what linux outputs coupled with the desire to not have some directory named that way. All of the mips architectures are implemented in the mips directory for userland. The kernel is as well, but that's a FreeBSDism, not required. There were once kernels that implemented things for a mips platform that were in directories like sgi, hpcmips, etc in both the pre-FreeBSD (4.4BSD and ported versions) as well as contemporary NetBSD platforms. FreeBSD used to have something similar for i386 and pc98. pc98 was the machine (the KERNEL side) and i386 was the ABI shared between MACHINE=i386 kernels and MACHINE=pc98 kernels.

Since I invented the MACHINE_CPUARCH concept, I can speak definitively to what it means.

[imp]

In D11986#248647, @bdrewery wrote:

In D11986#248646, @imp wrote:

In D11986#248631, @bdrewery wrote:

My initial attempts were rS302670 and rS302671 but I reverted it in rS302690 with reasoning:

MACHINE_CPUARCH smells like MACHINE except for arm64/aarch64 which
has it backwards.

This reasoning is sadly wrong. MACHINE_CPUARCH has nothing to do with MACHINE. The former is a userland construct while the latter is a kernel construct. The names are only accidentally related.

Ok, so perhaps only my change rS302671 was the problem and the original commit in rS302670 was fine.

Yea, I think that's right. There's an additional wrinkle in that TARGET* is supposed to only be a Makefile.inc construct, but Obrien used the same names for the gnu toolchain stuff creating lingering confusion (and the need for these macros in the first place). The TARGET* in the gnu Makefiles is a different beast allowing him, at the time, to incrementally build cross tools. These will go away soon, as we deoribit this stuff from the tree, and this tiny bit of confusion with it.

Also, sorry if I come across as a bit strident here, too many years of trying to document and police the confusion...

[imp]

Makefile

253

That could be a problem for this one instance, since we're guessing the TARGET from the TARGET_ARCH and aarch64 is an exception to the pattern...

share/mk/sys.mk

16

I may use that...