From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Wed, 21 Nov 2007 10:15:24 -0500 Subject: [U-Boot-Users] [PATCH] [BUILD] conditionally compile libfdt/*.c in libfdt/Makefile In-Reply-To: References: Message-ID: <47444B8C.7010503@ge.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Kumar Gala wrote: > Modify libfdt/Makefile to conditionally compile the *.c files based > on the board config. > > Signed-off-by: Kumar Gala > --- > > 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). Thanks to all! gvb