[coreboot] romtool and makefile breakage

[Stefan Reinauer]

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



-- 
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