On 05.04.2009 2:42 Uhr, Carl-Daniel Hailfinger wrote:
No offense intended, but almost every commit intended to fix the build since the introduction of romtool broke the build for some boards.
I'm very tempted to simply suggest reverting romtool until someone figures out how to get a reliable and stable abuild.
Please accept my apologies. If someone else did what I did last night, I would have been writing this mail, quite sure ;-)
We did test romtool/romfs over the last two weeks in a separate repository, and it never exposed the issues we were seeing.
I mean, look at the commits which tried to fix romtool breakage: 4049, 4054, 4061, 4062, 4067, 4068 and the build is still broken!
It should all be fixed again now. (Missing: Some PPC stuff). The revisions you list mostly fix different issues that did not show up in our tests before. Plus, the problem is we didn't have a ppc cross compiler installed on our development abuild boxes)
It seems the cause of the breakage is not understood.
The cause_s_ were quite simple. However, there were several.
Can we please require a full _parallel_ abuild on a _multicore/multiprocessor_ machine for each "bugfix" before it is committed?
Example: Broken rule:
makerule a depends "b" action "cp $< $@" end
Fixed rule: makerule a depends "b" action "cp $< $someuniquetempname" action "mv $someuniquetempname $@" end
I have to agree with Patrick here: If make can't handle trivial stuff like copying a file around without introducing a race condition or adding severe workarounds, it is probably not the tool of our choice.
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.
I don't like a BIOS to be smart about Make processes. Autoconf and libtool tried that, and failed. How could a BIOS ever succeed.
Maybe fixing GNU make instead would be an option, too? If make has a production rule for a target, it MUST (in the RFC sense) never ever execute a rule depending on that one, while the rule is still running. That's just broken behavior, by design or implementation, and I don't think our two layers of python on top of it should be fixing it. ;-)
Stefan