Andrew Wu wrote:
You can see util/crossgcc/Makefile :
all: build
build: bash ./buildgcc -G -p i386-elf bash ./buildgcc -G -p armv7a-eabi
IMNSHO this is a stupid problem seriously in need of an intelligent solution.
I can not understand the rationale for defaulting to what is clearly NOT the common case; i386 *and* armv7a.
This is not the first time that the above has caused problems, I can not understand why this was introduced in the first place (it seems pretty obvious that it will cause problems) and I can not understand why it is *still* there even after multiple problem reports.
Is every single developer suffering from total tunnel vision? Come on.
//Peter
On Mon, Sep 9, 2013 at 10:17 PM, Peter Stuge peter@stuge.se wrote:
Andrew Wu wrote:
You can see util/crossgcc/Makefile :
all: build
build: bash ./buildgcc -G -p i386-elf bash ./buildgcc -G -p armv7a-eabi
IMNSHO this is a stupid problem seriously in need of an intelligent solution.
I can not understand the rationale for defaulting to what is clearly NOT the common case; i386 *and* armv7a.
This is not the first time that the above has caused problems, I can not understand why this was introduced in the first place (it seems pretty obvious that it will cause problems) and I can not understand why it is *still* there even after multiple problem reports.
Is every single developer suffering from total tunnel vision? Come on.
I didn't want to say anything.
My locally modified util/crossgcc/Makefile does not do armv7, but instead:
bash ./buildgcc -j $(shell awk '/^processor/{n=n+1}END{print n+1}' /proc/cpuinfo) -p i386-elf
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.
Who is the maintainer of the build system? I assume someone who also administers gerrit, yes?
David