Re: git: 83bf6ab56829 - main - uname: switch machine to HW_MACHINE_ARCH

From: Mark Millard <marklmi_at_yahoo.com>
Date: Mon, 12 Dec 2022 21:49:03 UTC
On Dec 12, 2022, at 11:51, Mark Millard <marklmi@yahoo.com> wrote:

> Piotr Kubaj <pkubaj_at_anongoth.pl> wrote on
> Date: Mon, 12 Dec 2022 14:48:57 UTC :
> 
>> Reverted. Sorry for the breakage. I think will return with the next
>> version of this patch and this time I'll make sure to run make universe
>> on my powerpc64le instead of those pesky universe14 hosts :)
> 
> 
> I expect that any buildworld buildkernel that explicitly has TARGET and
> TARGET_ARCH set on the command line or in the environment might work,
> both cross builds and explicitly set to match the system doing the
> builds (explicit but actually native --in other worlds, a limiting
> condition of a cross build, a self-hosted cross-style build).
> 
> So I'm not sure that universe builds are a sufficient test context for
> the specific type of change: You likely need a set of tests that do
> not assign TARGET or TARGET_ARCH explicitly but are executed in
> environments that look to be native for each example architecture.
> You might need to ask folks with systems that you do not have examples
> of to do some testing of non-explicit native builds.

I left something implicit for the non-explicit testing
that may not be obvious: a full sequence for a test
seems to be something like:

A) from a pre-change context, build with the change
B) install the change and boot it
C) Try a native rebuild and install without any explicit
    TARGET/TARGET_ARCH assignment.

Making it through (C) should test the non-explicit case
for the kind of environment involved.

Of course, if (B) fails or leads to failure in (C),
recovering via more from-source build activity in that
messed up environment could be difficult. Using explicit
TARGET and TARGET_ARCH assignments might help?

===
Mark Millard
marklmi at yahoo.com