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

[Gerhard Sittig]

On Sun, Sep 08, 2013 at 10:42 +0900, Masahiro Yamada wrote:
> 
> First of all, this series convert makefiles in sub directories
> to Kbuild style.
> 
> What this series do is quite simple:
>  - Moving common lines in sub makefiles to a new file 'scripts/Makefile.build'
>  - Renaming COBJS-y and SOBJS-y to obj-y in each sub makefile.
>  - A little bit more tweaks
> 
> That's all.

OK, so you claim that nothing changes, except for the build
instructions, and that this is done in routine ways following
simple rules.  Source code need not get touched and is not
affected, features aren't broken, migration can be done in
several steps, etc ...  (this is a good thing, see below)

> Note1:
> This series breaks _NO_ features in U-Boot.
> Beucase it just moves common parts into scripts/Makefile.build
> 
> I believe no boards are broken by this refactoring, but
> it is humans who can make a mistake.
> So, it is very important to do build check before patches are applied.
> 
> I tested for ARM and Sandbox like this:
> 
>     $ CROSS_COMPILE_ARM=arm-linux-gnueabi- ./MAKEALL -a arm -a sandbox
> 
> and I got:
> 
>     --------------------- SUMMARY ----------------------------
>     Boards compiled: 336
>     ----------------------------------------------------------

This test only proves that the code compiles, nothing else.  Even
for a single board you may not run-test all features, given the
many functions and high interactivity and options that U-Boot
provides.  This becomes worse when your change affects several
more boards or even the whole tree (which is the case here).

I'd suggest a more formal approach to test or verification.
Being able to build the code (not having broken the compile
phase) is just a prerequisite.  But you want to prove that no
harm was done, i.e. that the code still is operational (at least
that it works as good as it did before the manipulation).

For editor sweep types of changes (for example renaming
identifiers while program flow and logic won't change) one may
verify that the changed textual representation of the source
still results in the same output for the machine.  This can be
achieved by e.g. md5 summing the object files or executables
(there may be differences, but only in the "envelope" which
carries timestamps or filenames, not in the generated code
itself).

Can you come up with a way to map executables generated by one
approach to executables generated by the other approach?  If you
still output the same set of files in the same locations, this
might already be given.  Can you then programmatically compare
the output files (either objects, or executables, depending on
which has less "false positives" or which involves less manual
comparison steps)?  This dramatically would increase certainty
that your modification does no harm, and is desirable.

Verifying that your modification to the build instructions still
results in the same binary output -- if done programmatically --
can free you of having to run-test the software (which is
complex, or impossible in the absence of hardware), and judge
whether you liked the result (which may be non-trivial as well
when you don't know what to expect).  Identical binary output
allows you to claim that the software will work the way it did
before your change without doubt. :)

> I could not test other architectures because I don't have suitable compiler.
> Especially PowerPC boards must be checked since I changed under arch/powerpc/
> in 0017.
> I will be grateful for any custodians' help.

Getting cross compilers for other architectures should be easy.
There's a prebuilt collection at kernel.org, so that you just
need to download any of them as the need arises.  See
ftp://ftp.kernel.org/pub/tools/crosstool/


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