On Tue, 2006-10-31 at 12:50 +0000, Thorsten Glaser wrote:
> Lothar Gesslein dixit:
> 
> >Methinks it's very neat, especially for developers who rebuild quite
> >often.
> 
> Especially developers should avoid such things, distcc too, in order
> to get reliable, reproducable results instead of Heisenbugs.
> 
> Just my 4+ years of experience leading a BSD operating system project,
> and this opinion is taken over from another 10+ year old OS project
> and has been validated by personal experience.

I just know enough happy users and am one myself. It is used for whole
projects and distributions. It is nothing new or hightech, i'd rate it
quite mature and well-known. I think it "just works (TM)".
The quick google search also didn't find any weird results that ccache
was blamed for. If it does not work as expected, it just fails to build.
Or?

> On the other hand, if people want to do such things, I'd say go ahead.
> Quoting is a little more difficult, though. I don't think GNU make has
> something like BSD ${varname:Q} which is what we need. In no case will
> you add the quotation marks to the variables themselves. I.e. you don't
> >So, i do $(TARGET_CC):= "ccache $(TARGET_CC)".
> 
> Instead, you'd fix the places where ${TARGET_CC} is used inappropriately.
> For instance:
> 
> target:
>       ${SHELL} some_script ${TARGET_CC} ...
>       ${TARGET_CC} ${TARGET_CFLAGS} -o $@ $>
>       ${MAKE} -C foo TARGET_CC="${TARGET_CC}" bar
> 
> Change the first line (because the shell script expects the compiler
> argument only as one positional parameter) but not the second or
> third line.

Yeah this is the way i've been doing it now. It's just so much places
where the quotes are missing ... even with the "legal" ones substracted,
and finding theese legals is quite hard for me.
I found the buildroot quite complex, and non-self-explaining (the
KERNEL_CROSS var for example, i use it for now because it works - but
don't understand every consequence) ... blame my lack of experience and
knowlendge.
I'll just try to produce something clean and as working as possbile, you
guys decide if you commit it.

First "prototype" attached, kernel + modules and some packages build
fine with ccache, but the major Makefiles fix is missing.

Please discuss further, i enjoyed the input so far :D

bye
-- 
Lothar Gesslein <[EMAIL PROTECTED]>
Index: package/Config.in
===================================================================
--- package/Config.in	(revision 1034)
+++ package/Config.in	(working copy)
@@ -369,6 +369,17 @@
 
 source "package/mypackage/Config.in"
 
+config FWRT_USE_CCACHE
+	bool "Use ccache to speed up re-compilation"
+	default n
+	help
+	  ccache is a compiler cache. It speeds up re-compilation of C/C++ code
+	  by caching previous compiles and detecting when the same compile is
+	  being done again.
+	  Requires ccache on your build machine.
+	  The default cache dir "$HOME/.ccache" is used unless otherwise
+	  specified in the CCACHE_DIR environment variable.
+
 source "package/Config.in.runtime"
 
 endmenu
Index: mk/vars.mk
===================================================================
--- mk/vars.mk	(revision 1034)
+++ mk/vars.mk	(working copy)
@@ -38,6 +38,12 @@
 KERNEL_CROSS:=		$(STAGING_DIR)/bin/$(OPTIMIZE_FOR_CPU)-linux-uclibc-
 TARGET_CROSS:=		$(STAGING_DIR)/bin/$(OPTIMIZE_FOR_CPU)-linux-uclibc-
 TARGET_CC:=		$(TARGET_CROSS)gcc
+TARGET_CXX:=		$(TARGET_CROSS)g++
+ifeq ($(FWRT_USE_CCACHE),y)
+KERNEL_CROSS:=		ccache $(KERNEL_CROSS)
+TARGET_CC:=		ccache $(TARGET_CROSS)gcc
+TARGET_CXX:=		ccache $(TARGET_CROSS)g++
+endif
 STRIP:=			$(STAGING_DIR)/bin/$(OPTIMIZE_FOR_CPU)-linux-uclibc-strip
 PATCH=			$(SCRIPT_DIR)/patch-kernel.sh
 SED:=			$(STAGING_DIR)/bin/sed -i -e
@@ -49,9 +55,9 @@
 			AS=$(TARGET_CROSS)as \
 			LD=$(TARGET_CROSS)ld \
 			NM=$(TARGET_CROSS)nm \
-			CC=$(TARGET_CROSS)gcc \
-			GCC=$(TARGET_CROSS)gcc \
-			CXX=$(TARGET_CROSS)g++ \
+			CC=$(TARGET_CC) \
+			GCC=$(TARGET_CC) \
+			CXX=$(TARGET_CXX) \
 			RANLIB=$(TARGET_CROSS)ranlib
 
 # invoke ipkg-build with some default options

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
freewrt-developers mailing list
[email protected]
https://www.freewrt.org/lists/listinfo/freewrt-developers

Reply via email to