[U-Boot-Users] [PATCH] [BUILD] conditionally compile libfdt/*.c in libfdt/Makefile

[Kumar Gala]

On Nov 21, 2007, at 9:15 AM, Jerry Van Baren wrote:

> Kumar Gala wrote:
>> Modify libfdt/Makefile to conditionally compile the *.c files based
>> on the board config.
>> Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
>> ---
>> This is against u-boot-testing
>> libfdt/Makefile       |    2 +-
>> libfdt/fdt.c          |    5 -----
>> libfdt/fdt_ro.c       |    5 -----
>> libfdt/fdt_rw.c       |    5 -----
>> libfdt/fdt_strerror.c |    5 -----
>> libfdt/fdt_sw.c       |    5 -----
>> libfdt/fdt_wip.c      |    5 -----
>> 7 files changed, 1 insertions(+), 31 deletions(-)
>
> Joy!
>
> It looks like the side effect of Grant's improvement just removed  
> all of the #ifdefs I hacked into the libfdt primary .c files.
>
> Side note: I was playing last night with the "what if" of deleting  
> (git rm libfdt/*.[ch]) all the "standard" libfdt code, then re- 
> importing it.  Effectively rebaselining in a kerchunk rather than a  
> patch-forward that Kumar has been doing.
>
> The advantages would be:
> * It would be clearer that u-boot/libfdt version 2007-11-X == dtc/ 
> libfdt version 2007-11-X and then we could more easily track changes  
> forward.
> * The removal patch is less than 40K (email list limit), but the re- 
> import patch is around 70K (IIRC) so that doesn't help.
>
> My current conclusion is that it isn't worth the effort.
> * The re-import still has a size vs. email list problem
> * Since some libfdt routines changed, other (client) routines must  
> be changed at the same time as the re-import (Kumar's patch rolls  
> libfdt forward _and_ fixes the handful of calls, so it doesn't have  
> a "broken spot" in between patches).

I've just created a libfdt_testing branch that is based on this patch  
+ u-boot-testing.

If you do a diff between dtc/libfdt and u-boot/libfdt we now see no  
differences.

- k