Re: [CFT] Buildworld ccache support

[Juan Ramón Molina Menor]

Hi Bryan.

Since ccache support was added to base in r290526 I’m not seeing the 
issues I had previously reported. I have now WITH_CCACHE_BUILD in 
src.conf and no make.conf and ccache is working as expected.


Thank you!
Juan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] Buildworld ccache support

[Bryan Drewery]

On 10/27/2015 10:27 PM, Simon J. Gerraty wrote:
> Bryan Drewery  wrote:
>> https://people.freebsd.org/~bdrewery/patches/world-ccache.diff
> 
> In the Junos build - where we used ccache for quite some time
> I did:
> 
> _CC := ${CC}
> CC = ${CCACHE_ENV} ${_CC}
> 
> Since sometimes you want the compiler without ccache - eg when linking.

Yes, I ended up changing the patch significantly to avoid using it for
mkdep and linking.  I moved away from using PATH as well since it is
obscure about whether ccache is being used or not.  I now always modify CC.

> 
> That needs to happen after CC is determined of course.
> 
> If the include of bsd.mkopt.mk were moved to after the inlcude of
> local.sys.env.mk, then you could simply:
> 
> __DEFAULT_NO_OPTIONS+= CCACHE_BUILD
> 
> there or in src.sys.env.mk
> 
>>
>> To use just set WITH_CCACHE_BUILD= in src.conf or make.conf.  I
>> purposely matched it to the same as the ports build.
>>
>> Thanks!


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: [CFT] Buildworld ccache support

[Simon J. Gerraty]

Bryan Drewery  wrote:
> https://people.freebsd.org/~bdrewery/patches/world-ccache.diff

In the Junos build - where we used ccache for quite some time
I did:

_CC := ${CC}
CC = ${CCACHE_ENV} ${_CC}

Since sometimes you want the compiler without ccache - eg when linking.

That needs to happen after CC is determined of course.

If the include of bsd.mkopt.mk were moved to after the inlcude of
local.sys.env.mk, then you could simply:

__DEFAULT_NO_OPTIONS+= CCACHE_BUILD

there or in src.sys.env.mk

> 
> To use just set WITH_CCACHE_BUILD= in src.conf or make.conf.  I
> purposely matched it to the same as the ports build.
> 
> Thanks!
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] Buildworld ccache support

[Bryan Drewery]

Why not cc me or even send this re: to the original thread?


On 10/20/2015 6:32 AM, Juan Ramón Molina Menor wrote:
> Hi!
> 
> I’m certainly doing it wrong, because CCACHE does not kick in after
> applying the patch and modifying make.conf. CCACHE stats ('ccache -z'
> followed by 'ccache -s') remain at zero during buildworld while they
> used to reflect the cache miss/hits before.
> 
> # cat /etc/make.conf
> WITH_CCACHE_BUILD=
> 
>  # svn diff /usr/src/share/mk/local.init.mk
> Index: /usr/src/share/mk/local.init.mk
> ===
> --- /usr/src/share/mk/local.init.mk (revision 289627)
> +++ /usr/src/share/mk/local.init.mk (working copy)
> @@ -38,3 +38,37 @@
>  HOST_CFLAGS+= -DHOSTPROG
>  CFLAGS+= ${HOST_CFLAGS}
>  .endif
> +
> +# Handle ccache after CC is determined.  If CC is at some specific path
> then
> +# we must prepend the ccache wrapper.  Otherwise we can just prepend
> PATH with
> +# the wrapper location, which is a more safe solution since it avoids
> spaces
> +# and compiler type guessing based on filename.
> +LOCALBASE?=/usr/local
> +CCACHE_WRAPPER_PATH?=  ${LOCALBASE}/libexec/ccache
> +CCACHE_PATH?=  ${LOCALBASE}/bin/ccache
> +.if defined(WITH_CCACHE_BUILD) && !defined(NOCCACHE) && \
> +${CC:M*ccache*} == "" && exists(${CCACHE_PATH})
> +# Handle compiler changes properly.  This avoids needing to use the
> 'world'
> +# wrappers.
> +CCACHE_COMPILERCHECK?= content
> +.export CCACHE_COMPILERCHECK
> +.if ${CC:M/*} == ""
> +# Can use PATH.
> +PATH:= ${CCACHE_WRAPPER_PATH}:${PATH}
> +.export PATH
> +.else
> +# Must prepend CC.
> +CC:=   ${CCACHE_PATH} ${CC}
> +CXX:=  ${CCACHE_PATH} ${CXX}
> +CPP:=  ${CCACHE_PATH} ${CPP}
> +.if defined(HOST_CC)
> +HOST_CC:=  ${CCACHE_PATH} ${HOST_CC}
> +.endif
> +.if defined(HOST_CXX)
> +HOST_CXX:= ${CCACHE_PATH} ${HOST_CXX}
> +.endif
> +.if defined(HOST_CPP)
> +HOST_CPP:= ${CCACHE_PATH} ${HOST_CPP}
> +.endif
> +.endif
> +.endif # WITH_CCACHE_BUILD
> 
> If I recover the old make.conf, CCACHE works again for a buildworld.
> 
> # cat /etc/make.conf.old
> .if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*))
> .if !defined(NOCCACHE) && exists(/usr/local/libexec/ccache/world/cc)
> CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1}
> CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1}
> .endif
> .endif
> 
> Maybe I misconfigured CCACHE when I first installed it?
> 

This doesn't check for a value of WITH_CCACHE_BUILD, just being defined
is enough.

I've been fixing some subtle bugs such as in the lib32 build, but
overall I've had ccache -s growing while using the patch.  If you
already have ccache in CC it won't apply it.

Are you building head from head or some other configuration?


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: [CFT] Buildworld ccache support

[Juan Ramón Molina Menor]

Hi Bryan.


Why not cc me or even send this re: to the original thread?


I’m not used to mailing lists etiquette, sorry. I thought receiving two 
copies of the same message would bother you. Now I realize there are 
digests and maybe other less direct methods for message delivery.


Best regards,
Juan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] Buildworld ccache support

[Juan Ramón Molina Menor]

Why not cc me or even send this re: to the original thread?


On 10/20/2015 6:32 AM, Juan Ramón Molina Menor wrote:

Hi!

I’m certainly doing it wrong, because CCACHE does not kick in after
applying the patch and modifying make.conf. CCACHE stats ('ccache -z'
followed by 'ccache -s') remain at zero during buildworld while they
used to reflect the cache miss/hits before.

# cat /etc/make.conf
WITH_CCACHE_BUILD=

 # svn diff /usr/src/share/mk/local.init.mk
Index: /usr/src/share/mk/local.init.mk
===
--- /usr/src/share/mk/local.init.mk (revision 289627)
+++ /usr/src/share/mk/local.init.mk (working copy)
@@ -38,3 +38,37 @@
 HOST_CFLAGS+= -DHOSTPROG
 CFLAGS+= ${HOST_CFLAGS}
 .endif
+
+# Handle ccache after CC is determined.  If CC is at some specific path
then
+# we must prepend the ccache wrapper.  Otherwise we can just prepend
PATH with
+# the wrapper location, which is a more safe solution since it avoids
spaces
+# and compiler type guessing based on filename.
+LOCALBASE?=/usr/local
+CCACHE_WRAPPER_PATH?=  ${LOCALBASE}/libexec/ccache
+CCACHE_PATH?=  ${LOCALBASE}/bin/ccache
+.if defined(WITH_CCACHE_BUILD) && !defined(NOCCACHE) && \
+${CC:M*ccache*} == "" && exists(${CCACHE_PATH})
+# Handle compiler changes properly.  This avoids needing to use the
'world'
+# wrappers.
+CCACHE_COMPILERCHECK?= content
+.export CCACHE_COMPILERCHECK
+.if ${CC:M/*} == ""
+# Can use PATH.
+PATH:= ${CCACHE_WRAPPER_PATH}:${PATH}
+.export PATH
+.else
+# Must prepend CC.
+CC:=   ${CCACHE_PATH} ${CC}
+CXX:=  ${CCACHE_PATH} ${CXX}
+CPP:=  ${CCACHE_PATH} ${CPP}
+.if defined(HOST_CC)
+HOST_CC:=  ${CCACHE_PATH} ${HOST_CC}
+.endif
+.if defined(HOST_CXX)
+HOST_CXX:= ${CCACHE_PATH} ${HOST_CXX}
+.endif
+.if defined(HOST_CPP)
+HOST_CPP:= ${CCACHE_PATH} ${HOST_CPP}
+.endif
+.endif
+.endif # WITH_CCACHE_BUILD

If I recover the old make.conf, CCACHE works again for a buildworld.

# cat /etc/make.conf.old
.if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*))
.if !defined(NOCCACHE) && exists(/usr/local/libexec/ccache/world/cc)
CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1}
CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1}
.endif
.endif

Maybe I misconfigured CCACHE when I first installed it?



This doesn't check for a value of WITH_CCACHE_BUILD, just being defined
is enough.

I've been fixing some subtle bugs such as in the lib32 build, but
overall I've had ccache -s growing while using the patch.  If you
already have ccache in CC it won't apply it.

Are you building head from head or some other configuration?


HEAD from HEAD, updated regularly in /usr/src with SVN. Following the 
standard procedure for updating described in /usr/src/UPDATING. ccache 
installed as explained by the package message. Nothing special, really.


I’ll take some time when possible to recheck all the settings and be 
back to you.


Best regards,
Juan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] Buildworld ccache support

[Bryan Drewery]

On 10/21/2015 1:44 PM, Juan Ramón Molina Menor wrote:
> +.if ${CC:M/*} == ""
> +# Can use PATH.
> +PATH:= ${CCACHE_WRAPPER_PATH}:${PATH}

These lines in particular did have problems that I fixed recently.

- It would potentially add /usr/local/libexec/ccache into PATH multiple
times in sub-makes (I think, it may have been my own PATH confusing me).
This would still use ccache.
- It would consider the '-isystem /usr/obj/...' used for LIB32MAKE to
match on '${CC:M/*}' which is intended to see if the compiler itself
starts with a /. In this case of building during build32 ccache was not
used.

I have since added 'env CCACHE=1' to CC and an .info ${PATH} near this
code to see if it is working and it sure seems to be working in all of
the build.  This does suggest that using the PATH method may not be good
as it leads to confusion about whether it is used or not.

I have seen ccache stats get really messed up before.  They seemed stuck
to me earlier.  I had updated ccache in ports recently and had been
building Poudriere using my global ccache dir.  Outside of the jail I
still had the older ccache.  This may have led to it messing up my cache
and stats.  Once I upgraded ccache in the host and cleaned the cache it
seemed to resume incrementing the counters.

I've also since removed the CCP handling from the patch as I found that
ccache just records a stat and bails out in that case.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: [CFT] Buildworld ccache support

[Bryan Drewery]

On 10/21/2015 3:13 PM, Bryan Drewery wrote:
> On 10/21/2015 1:44 PM, Juan Ramón Molina Menor wrote:
>> +.if ${CC:M/*} == ""
>> +# Can use PATH.
>> +PATH:= ${CCACHE_WRAPPER_PATH}:${PATH}
> 
> These lines in particular did have problems that I fixed recently.
> 
> - It would potentially add /usr/local/libexec/ccache into PATH multiple
> times in sub-makes (I think, it may have been my own PATH confusing me).
> This would still use ccache.
> - It would consider the '-isystem /usr/obj/...' used for LIB32MAKE to
> match on '${CC:M/*}' which is intended to see if the compiler itself
> starts with a /. In this case of building during build32 ccache was not
> used.
> 
> I have since added 'env CCACHE=1' to CC and an .info ${PATH} near this
> code to see if it is working and it sure seems to be working in all of
> the build.  This does suggest that using the PATH method may not be good
> as it leads to confusion about whether it is used or not.
> 
> I have seen ccache stats get really messed up before.  They seemed stuck
> to me earlier.  I had updated ccache in ports recently and had been
> building Poudriere using my global ccache dir.  Outside of the jail I
> still had the older ccache.  This may have led to it messing up my cache
> and stats.  Once I upgraded ccache in the host and cleaned the cache it
> seemed to resume incrementing the counters.
> 
> I've also since removed the CCP handling from the patch as I found that
> ccache just records a stat and bails out in that case.
> 

Subtle changes in the environment or make command line could not use the
cache too. Some of my recent changes in the build system may have caused
no cache to be used in the next build.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: [CFT] Buildworld ccache support

[Freddie Cash]

On Tue, Oct 20, 2015 at 6:32 AM, Juan Ramón Molina Menor 
wrote:

> Hi!
>
> I’m certainly doing it wrong, because CCACHE does not kick in after
> applying the patch and modifying make.conf. CCACHE stats ('ccache -z'
> followed by 'ccache -s') remain at zero during buildworld while they used
> to reflect the cache miss/hits before.
>
> # cat /etc/make.conf
> WITH_CCACHE_BUILD=
>

​You need to actually set this to a value, in order for the variable to be
defined.

WITH_CCACHE_BUILD=yes
WITH_CCACHE_BUILD=something
WITH_CCACHE_BUILD=whatever

It doesn't matter what it's set to, but it has to be set to something.​




> ​
>  # svn diff /usr/src/share/mk/local.init.mk
> Index: /usr/src/share/mk/local.init.mk
> ===
> --- /usr/src/share/mk/local.init.mk (revision 289627)
> +++ /usr/src/share/mk/local.init.mk (working copy)
> @@ -38,3 +38,37 @@
>  HOST_CFLAGS+= -DHOSTPROG
>  CFLAGS+= ${HOST_CFLAGS}
>  .endif
> +
> +# Handle ccache after CC is determined.  If CC is at some specific path
> then
> +# we must prepend the ccache wrapper.  Otherwise we can just prepend PATH
> with
> +# the wrapper location, which is a more safe solution since it avoids
> spaces
> +# and compiler type guessing based on filename.
> +LOCALBASE?=/usr/local
> +CCACHE_WRAPPER_PATH?=  ${LOCALBASE}/libexec/ccache
> +CCACHE_PATH?=  ${LOCALBASE}/bin/ccache
> +.if defined(WITH_CCACHE_BUILD) && !defined(NOCCACHE) && \
>

​This line here checks if the variable is defined (meaning, that it is set
to something), and if it is, then the code after it enabled CCACHE.​

-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] Buildworld ccache support

[Juan Ramón Molina Menor]

Le 20/10/2015 17:50, Freddie Cash a écrit :

On Tue, Oct 20, 2015 at 6:32 AM, Juan Ramón Molina Menor >wrote:

Hi!

I’m certainly doing it wrong, because CCACHE does not kick in after
applying the patch and modifying make.conf. CCACHE stats ('ccache
-z' followed by 'ccache -s') remain at zero during buildworld while
they used to reflect the cache miss/hits before.

# cat /etc/make.conf
WITH_CCACHE_BUILD=


​You need to actually set this to a value, in order for the variable to
be defined.

WITH_CCACHE_BUILD=yes
WITH_CCACHE_BUILD=something
WITH_CCACHE_BUILD=whatever

It doesn't matter what it's set to, but it has to be set to something.​


Thanks for the tip, but I had already tried. Unfortunately there is 
something else which escapes me…


Best regards,
Juan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] Buildworld ccache support

[Bryan Drewery]

> On Oct 15, 2015, at 17:31, Warren Block  wrote:
> 
>> On Thu, 15 Oct 2015, Bryan Drewery wrote:
>> 
>> Hi,
>> 
>> If you are interested in using ccache in buildworld please consider
>> using this patch locally and giving me some feedback.  The current
>> advice for ccache+buildworld (the CC:= trick in make.conf) actually
>> results in the build thinking you are using a cross-compiler which
>> results in unintended side-effects.  It also doesn't work with meta mode
>> as it handles CC and toolchain differently.  This patch intends to cover
>> all cases.
>> 
>> https://people.freebsd.org/~bdrewery/patches/world-ccache.diff
>> 
>> To use just set WITH_CCACHE_BUILD= in src.conf or make.conf.  I
>> purposely matched it to the same as the ports build.
> 
> Will this work on -stable?

No but I could likely adapt it for there too. I'm more cautious about putting 
this there since I never build stable.

Bryan 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] Buildworld ccache support

[Warren Block]

On Thu, 15 Oct 2015, Bryan Drewery wrote:


Hi,

If you are interested in using ccache in buildworld please consider
using this patch locally and giving me some feedback.  The current
advice for ccache+buildworld (the CC:= trick in make.conf) actually
results in the build thinking you are using a cross-compiler which
results in unintended side-effects.  It also doesn't work with meta mode
as it handles CC and toolchain differently.  This patch intends to cover
all cases.

https://people.freebsd.org/~bdrewery/patches/world-ccache.diff

To use just set WITH_CCACHE_BUILD= in src.conf or make.conf.  I
purposely matched it to the same as the ports build.


Will this work on -stable?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"