<sphalerite_>
Sonarpulse: my suggestion was setting the host_alias/build_alias env vars instead of --host/--build
<Sonarpulse>
sphalerite_: I haven't even heard of those hmmm
<sphalerite_>
same effect, just that they won't affect non-autotools stuff
<sphalerite_>
but I think it's probably better to stick to the (slightly) well-trodden path
<sphalerite_>
setting them does work, I've tested that. But I don't really see any real benefit in it
<Sonarpulse>
sphalerite_: ooooohhhhh
<Sonarpulse>
i see
<Sonarpulse>
so we don't need configurePlatforms = [] so much
<Sonarpulse>
hmm good point
<sphalerite_>
exactly
<sphalerite_>
but it's significantly more obscure
<Sonarpulse>
sphalerite_: if we do the "always prefix everywhere thing"
<Sonarpulse>
well
<Sonarpulse>
hmm
<Sonarpulse>
basically i was going to say always define those env vars, even for native builds
<Sonarpulse>
but then i don't want to skip configure tests for native builds I think?
<sphalerite_>
yes I agree with always setting them everywhere, especially given how painful it's been so far getting that aarch64 machine to build armv7 stuff natively
<Sonarpulse>
sphalerite_: most of the tests are guardeed by the like CROSS_COMPILING shell var
<Sonarpulse>
I htink
<Sonarpulse>
I wonder if you can set the aliases but then force that false when they are the same
<Sonarpulse>
Cause I think --build foo --host foo (same foo) will enable cross compiling
<sphalerite_>
right now I'm trying to fix the bootstrap — some stage of binutils is autodetecting it as aarch64 which breaks later on
<Sonarpulse>
which I am normally super down with, but sometimes those native-only tests are important
<Sonarpulse>
sphalerite_: ahhhh, sub configure?
<Sonarpulse>
here's a secret, all of binutils is actually multi-target *except* for AS
<Sonarpulse>
its sooooo tantilizingly close
<sphalerite_>
yeah it's throwing up on -march=armv7-a later on