On Wed, Jun 28, 2017 at 6:29 PM, James Le Cuirot <[email protected]> wrote: > On Wed, 28 Jun 2017 17:52:26 -0400 > Mike Gilbert <[email protected]> wrote: > >> On Tue, Jun 27, 2017 at 6:44 PM, James Le Cuirot <[email protected]> wrote: >> > I am therefore proposing a new global big-endian flag. This could be >> > masked by default and unmasked + forced in the relevant profiles under >> > arch. I will apply this according to the mapping defined in tc-endian of >> > toolchain-funcs.eclass. > > I've just been putting the patch together. I made it slightly simpler > by masking *and* forcing it by default so that it only needs to be > unmasked were necessary. > >> A possible alternative would be to create a new USE_EXPAND variable >> for this. That would allow for easier expansion in case we ever >> support something other than big/little endian machines. > > That way madness lies? Wikipedia talks about middle-endian as being the > catch all for other random orderings that have appeared over the years > but I don't think any of them were used on a system-wide basis. I can't > imagine Linux ever supporting such a thing. Unless you're talking about > dealing with soft vs hard float here too?
No, I'm not referring to anything specifically. Just wanted to point out the possibility of having a multi-value variable instead of a boolean. If that seems very un-useful, please disregard.
