<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 9, 2013 at 10:17 PM, Peter Stuge <span dir="ltr"><<a href="mailto:peter@stuge.se" target="_blank">peter@stuge.se</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Andrew Wu wrote:<br>
> You can see util/crossgcc/Makefile :<br>
><br>
><br>
> all: build<br>
><br>
> build:<br>
>     bash ./buildgcc -G -p i386-elf<br>
>     bash ./buildgcc -G -p armv7a-eabi<br>
<br>
IMNSHO this is a stupid problem seriously in need of an intelligent<br>
solution.<br>
<br>
I can not understand the rationale for defaulting to what is clearly<br>
NOT the common case; i386 *and* armv7a.<br>
<br>
This is not the first time that the above has caused problems, I can<br>
not understand why this was introduced in the first place (it seems<br>
pretty obvious that it will cause problems) and I can not understand<br>
why it is *still* there even after multiple problem reports.<br>
<br>
Is every single developer suffering from total tunnel vision? Come on.<br>
<span class=""><font color="#888888"></font></span></blockquote><div><br></div><div>I didn't want to say anything.<br><br>My locally modified util/crossgcc/Makefile does not do armv7, but instead:<br><br>bash ./buildgcc -j $(shell awk '/^processor/{n=n+1}END{print n+1}' /proc/cpuinfo) -p i386-elf<br>
<br></div>It would be preferable to read /sys/devices/system/cpu/online but the format is not machine-friendly which would make for a lot of coding to work around it.<br><br></div><div class="gmail_quote">Who is the maintainer of the build system? I assume someone who also administers gerrit, yes?<br>
<br>David<br></div></div></div>