Optimize the handling of big/little endian determination.

[stevek]

Summary

Add variables to contain lists of MACHINE_ARCH values to use
to determine little or big endian.

Only error out about not being able to determine endianess if
TARGET_ENDIANNESS is empty and not cross-compiling.

Obtained from: Juniper Networks, Inc.

[stevek]

Update summary

[stevek]

Adjusted little endian list

[emaste]

I'm a little confused by this change - it doesn't seem notably clearer to me. There seems to be a functional change/improvement that isn't really described in the commit message.

[stevek]

In D44629#1071811, @emaste wrote:

I'm a little confused by this change - it doesn't seem notably clearer to me.

In what way? A set of lists is often easier to manage (and clearer, especially in a diff) than a pile of or'd conditional expressions.

There seems to be a functional change/improvement that isn't really described in the commit message.

Are you referring to the host part?

[emaste]

A set of lists is often easier to manage (and clearer, especially in a diff) than a pile of or'd conditional expressions.

I think it's a bit of a toss-up -- the set of targets in the two lists is not large and does not change frequently. I'll grant you that the two lists are somewhat nicer than the large set if if-or conditions, but N_$e= ${MACHINE_ARCH_LIST.$e:@m@N$m@:ts:} makes up for it by taking a while to figure out.

Is the host change fixing a bug?

[stevek]

In D44629#1072114, @emaste wrote:

A set of lists is often easier to manage (and clearer, especially in a diff) than a pile of or'd conditional expressions.

I think it's a bit of a toss-up -- the set of targets in the two lists is not large and does not change frequently. I'll grant you that the two lists are somewhat nicer than the large set if if-or conditions, but N_$e= ${MACHINE_ARCH_LIST.$e:@m@N$m@:ts:} makes up for it by taking a while to figure out.

It's a bit of a toss-up from an understanding standpoint, I suppose, if one is not used to doing that sort of manipulation. At Juniper, we have been using this sort of construct with bmake for many years, so it is somewhat second nature at this point.

Is the host change fixing a bug?

Yes, the host change fixes a bug that can occur when building with dirdeps build.

[sjg]

share/mk/bsd.endian.mk

16

I thnk you could simplify this with M_ListToSkip:

N_$e = ${MACHINE_ARCH_LIST.$e:${M_ListToSkip}}

possibly use := too

26

FWIW I find this sort of construct scales (mentally) far better than a or'd list of conditionals. Here is is quite clear that we are after arches which are little endian.

Granted some folk find :M a more natural test than :N but the later as the huge advantage of being cumulative. Testing multiple values using :M is more complicated (see M_ListToMatch in share/mk/local.sys.env.mk)

[stevek]

Updated to use ${M_ListToSkip}

[sjg]

Looks ok to me

share/mk/bsd.endian.mk

47

edianness? or however that would be spelt