Am 05.04.2009 02:42, schrieb Carl-Daniel Hailfinger:
No offense intended, but almost every commit intended to fix the build
since the introduction of romtool broke the build for some boards.
As long as someone works on it, I think it's fine. If problems arise and
no-one works on fixing them, that's a serious issue and code should be
rolled back.
That's why this is a development repository. And people who fear that
their local copy might break can look at the autobuilder.
It seems the cause of the breakage is not understood.
Can we please require a full _parallel_ abuild on a
_multicore/multiprocessor_ machine for each "bugfix" before it is committed?
Doesn't necessarily help. Many of my patches were tested exactly that
way, and they worked fine on _my_ box when built that way. What more
should I do?
If you want an "tree-always-works" process, I can recommend aegis
(http://aegis.sf.net)
"cp" and "cat" should be banned in makefiles. They are not atomic and if
[...]
And while we're on the topic of makefile race conditions, please note
that gcc is smart enough to create output files atomically, but almost
every other program (romcc, romtool, cat, cp) is not. Non-smart programs
MUST (in the RFC sense) always output to files not specified in any
dependency rule. Creating smart programs is hard.
How about just banning make, if it doesn't manage such a trivial thing
such as looking if the job make itself created finished, before assuming
that the file is ready to be used?
This isn't rocket science.
Patrick
--
coreboot mailing list: [email protected]
http://www.coreboot.org/mailman/listinfo/coreboot
