[coreboot] romtool and makefile breakage
stepan at coresystems.de
Sun Apr 5 10:13:48 CEST 2009
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?
> Broken rule:
> makerule a
> depends "b"
> action "cp $< $@"
> Fixed rule:
> makerule a
> depends "b"
> action "cp $< $someuniquetempname"
> action "mv $someuniquetempname $@"
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. ;-)
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
More information about the coreboot