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