[U-Boot] [PATCH 00/19] First step towards Kbuild: Use Kbuild style makefiles

[Gerhard Sittig]

On Tue, Sep 17, 2013 at 09:35 +0900, Masahiro Yamada wrote:
> 
> > [ Makefiles rearranged, how to verify the change? ]
> 
> But your suggestion sounds interesting.
> If we could programmatically compare the generated executables
> in an easy way, that would be worth checking.
> 
> So I gave it a try.
> Finally it turned out to be much harder than I had expected. (Almost nightware)
> 
> Anyway, let's see what I did one by one.
> 
> [ ... time stamps, version information, symbol order, etc ... ]
> 
> (10) Results
> 
> [ ... most architectures, matching md5sum ... ]
> 
> (12) Conclusion
> 
> I made as much effort as I could do now
> in order to get md5sum matching.
> 
> I found one file (arch/powerpc/cpu/mpc8260/Makefile)
> to be fixed. (Working but better to be fixed.)
> 
> I will post version2 with this fix plus rebased on the current master.

What a fine display of Lemming control^H^H^H^W^W persistence. :)

Woah, this is awesome!  You spent a lot of effort to verify the
results, and further improved the series upon detecting a
previously unspotted difference.  This is very much appreciated.

So you gained even more confidence in the change and have proven
that apart from the wanted modification nothing else is affected.
This is a very good thing!  Especially since the nature of the
bootloader's project is rather sensitive to not passing a flag,
or passing a wrong flag to architecture specific code.

The essence of your notes (the spots of potential conflict, how
to "unify" them to shadow "unwanted diffs", and how to compare
results after building most of the targets) are worth keeping
around somewhere, I guess.  Those who setup build and test farms
may want to reference them.  For now it's in the ML archive.


> I could not compile lots of minor architecture boards,
> but the results of md5sum for arm, powerpc, sandbox architectures
> is sufficient to support my correctness.
> 
> But I want to know the reason why the compile failed for such many boards.
> Of course my procedure might be wrong, but I think at least some of warnings
> are caused by immature code. I mean more or less boards look to be already broken.

That was my other motivation for the "compare binaries" approach
in contrast to run-testing the result on the targets.

You want to prove that your modification only has wanted effects
and does nothing else, regardless of which state you initially
find the source code in.  Not being able to build need not mean
that you broke it, it might have been in this state before
already.  And not being able to run software in the absence of
hardware may even be the rule instead of an exception.

Getting those targets to build again which currently don't
appears to be a separate task, independent from your modification
(re-write) of the build instructions.


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de