Patchwork Add support for ccache builds with the SDK

login
register
mail settings
Submitter Laszlo Papp
Date Aug. 22, 2014, 3:20 p.m.
Message ID <1408720803-11737-1-git-send-email-lpapp@kde.org>
Download mbox | patch
Permalink /patch/78829/
State New
Headers show

Comments

Laszlo Papp - Aug. 22, 2014, 3:20 p.m.
Signed-off-by: Laszlo Papp <lpapp@kde.org>
---
 meta/classes/toolchain-scripts.bbclass | 2 ++
 1 file changed, 2 insertions(+)
Laszlo Papp - Aug. 29, 2014, 10:55 a.m.
One week passed and there is neither feedback, nor progress. What am I
doing wrong?

On Fri, Aug 22, 2014 at 4:20 PM, Laszlo Papp <lpapp@kde.org> wrote:
> Signed-off-by: Laszlo Papp <lpapp@kde.org>
> ---
>  meta/classes/toolchain-scripts.bbclass | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/meta/classes/toolchain-scripts.bbclass b/meta/classes/toolchain-scripts.bbclass
> index 6cc8eba..60278d6 100644
> --- a/meta/classes/toolchain-scripts.bbclass
> +++ b/meta/classes/toolchain-scripts.bbclass
> @@ -19,6 +19,7 @@ toolchain_create_sdk_env_script () {
>                 EXTRAPATH="$EXTRAPATH:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_ARCH}${TARGET_VENDOR}-$i"
>         done
>         echo 'export PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$PATH' >> $script
> +       echo 'export CCACHE_PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$CCACHE_PATH' >> $script
>         echo 'export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT' >> $script
>         echo 'export PKG_CONFIG_PATH=$SDKTARGETSYSROOT'"$libdir"'/pkgconfig' >> $script
>         echo 'export CONFIG_SITE=${SDKPATH}/site-config-'"${multimach_target_sys}" >> $script
> @@ -37,6 +38,7 @@ toolchain_create_tree_env_script () {
>         rm -f $script
>         touch $script
>         echo 'export PATH=${STAGING_DIR_NATIVE}/usr/bin:${PATH}' >> $script
> +       echo 'export CCACHE_PATH=${STAGING_DIR_NATIVE}/usr/bin:${CCACHE_PATH}' >> $script
>         echo 'export PKG_CONFIG_SYSROOT_DIR=${PKG_CONFIG_SYSROOT_DIR}' >> $script
>         echo 'export PKG_CONFIG_PATH=${PKG_CONFIG_PATH}' >> $script
>         echo 'export CONFIG_SITE="${@siteinfo_get_files(d)}"' >> $script
> --
> 2.0.4
>
Saul Wold - Aug. 29, 2014, 6:29 p.m.
Might be a nit, but can you please follow the Commit Guildlines at
http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines

The summary should include the filename or area of the fix

toolchain-script: Add ...

Also can you expand on the why this is needed?

Thanks
	Sau!

On 08/22/2014 08:20 AM, Laszlo Papp wrote:
> Signed-off-by: Laszlo Papp <lpapp@kde.org>
> ---
>   meta/classes/toolchain-scripts.bbclass | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/meta/classes/toolchain-scripts.bbclass b/meta/classes/toolchain-scripts.bbclass
> index 6cc8eba..60278d6 100644
> --- a/meta/classes/toolchain-scripts.bbclass
> +++ b/meta/classes/toolchain-scripts.bbclass
> @@ -19,6 +19,7 @@ toolchain_create_sdk_env_script () {
>   		EXTRAPATH="$EXTRAPATH:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_ARCH}${TARGET_VENDOR}-$i"
>   	done
>   	echo 'export PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$PATH' >> $script
> +	echo 'export CCACHE_PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$CCACHE_PATH' >> $script
>   	echo 'export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT' >> $script
>   	echo 'export PKG_CONFIG_PATH=$SDKTARGETSYSROOT'"$libdir"'/pkgconfig' >> $script
>   	echo 'export CONFIG_SITE=${SDKPATH}/site-config-'"${multimach_target_sys}" >> $script
> @@ -37,6 +38,7 @@ toolchain_create_tree_env_script () {
>   	rm -f $script
>   	touch $script
>   	echo 'export PATH=${STAGING_DIR_NATIVE}/usr/bin:${PATH}' >> $script
> +	echo 'export CCACHE_PATH=${STAGING_DIR_NATIVE}/usr/bin:${CCACHE_PATH}' >> $script
>   	echo 'export PKG_CONFIG_SYSROOT_DIR=${PKG_CONFIG_SYSROOT_DIR}' >> $script
>   	echo 'export PKG_CONFIG_PATH=${PKG_CONFIG_PATH}' >> $script
>   	echo 'export CONFIG_SITE="${@siteinfo_get_files(d)}"' >> $script
>
Laszlo Papp - Sept. 1, 2014, 5:34 p.m.
It is indeed nit, and not something I wishfully spend my time with, so
feel free to rewrite the commit message and integrate the ccache
support. As usual, this feature is also applied in our fork, so I am
fine... It is only the upstream Yocto users who may be missing
features out.

Having said that, thank you for your feedback.

On Fri, Aug 29, 2014 at 7:29 PM, Saul Wold <sgw@linux.intel.com> wrote:
>
> Might be a nit, but can you please follow the Commit Guildlines at
> http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
>
> The summary should include the filename or area of the fix
>
> toolchain-script: Add ...
>
> Also can you expand on the why this is needed?
>
> Thanks
>         Sau!
>
>
> On 08/22/2014 08:20 AM, Laszlo Papp wrote:
>>
>> Signed-off-by: Laszlo Papp <lpapp@kde.org>
>> ---
>>   meta/classes/toolchain-scripts.bbclass | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/meta/classes/toolchain-scripts.bbclass
>> b/meta/classes/toolchain-scripts.bbclass
>> index 6cc8eba..60278d6 100644
>> --- a/meta/classes/toolchain-scripts.bbclass
>> +++ b/meta/classes/toolchain-scripts.bbclass
>> @@ -19,6 +19,7 @@ toolchain_create_sdk_env_script () {
>>
>> EXTRAPATH="$EXTRAPATH:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_ARCH}${TARGET_VENDOR}-$i"
>>         done
>>         echo 'export
>> PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$PATH'
>> >> $script
>> +       echo 'export
>> CCACHE_PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$CCACHE_PATH'
>> >> $script
>>         echo 'export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT' >> $script
>>         echo 'export
>> PKG_CONFIG_PATH=$SDKTARGETSYSROOT'"$libdir"'/pkgconfig' >> $script
>>         echo 'export
>> CONFIG_SITE=${SDKPATH}/site-config-'"${multimach_target_sys}" >> $script
>> @@ -37,6 +38,7 @@ toolchain_create_tree_env_script () {
>>         rm -f $script
>>         touch $script
>>         echo 'export PATH=${STAGING_DIR_NATIVE}/usr/bin:${PATH}' >>
>> $script
>> +       echo 'export
>> CCACHE_PATH=${STAGING_DIR_NATIVE}/usr/bin:${CCACHE_PATH}' >> $script
>>         echo 'export PKG_CONFIG_SYSROOT_DIR=${PKG_CONFIG_SYSROOT_DIR}' >>
>> $script
>>         echo 'export PKG_CONFIG_PATH=${PKG_CONFIG_PATH}' >> $script
>>         echo 'export CONFIG_SITE="${@siteinfo_get_files(d)}"' >> $script
>>
>
Laszlo Papp - Sept. 1, 2014, 5:47 p.m.
Just in case the severity is not clear. Without this change, the Yocto
SDK breaks the build for our software since we do prefer to use ccache
for speeding the build process up. We are probably not alone with that
...

On Mon, Sep 1, 2014 at 6:34 PM, Laszlo Papp <lpapp@kde.org> wrote:
> It is indeed nit, and not something I wishfully spend my time with, so
> feel free to rewrite the commit message and integrate the ccache
> support. As usual, this feature is also applied in our fork, so I am
> fine... It is only the upstream Yocto users who may be missing
> features out.
>
> Having said that, thank you for your feedback.
>
> On Fri, Aug 29, 2014 at 7:29 PM, Saul Wold <sgw@linux.intel.com> wrote:
>>
>> Might be a nit, but can you please follow the Commit Guildlines at
>> http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
>>
>> The summary should include the filename or area of the fix
>>
>> toolchain-script: Add ...
>>
>> Also can you expand on the why this is needed?
>>
>> Thanks
>>         Sau!
>>
>>
>> On 08/22/2014 08:20 AM, Laszlo Papp wrote:
>>>
>>> Signed-off-by: Laszlo Papp <lpapp@kde.org>
>>> ---
>>>   meta/classes/toolchain-scripts.bbclass | 2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/meta/classes/toolchain-scripts.bbclass
>>> b/meta/classes/toolchain-scripts.bbclass
>>> index 6cc8eba..60278d6 100644
>>> --- a/meta/classes/toolchain-scripts.bbclass
>>> +++ b/meta/classes/toolchain-scripts.bbclass
>>> @@ -19,6 +19,7 @@ toolchain_create_sdk_env_script () {
>>>
>>> EXTRAPATH="$EXTRAPATH:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_ARCH}${TARGET_VENDOR}-$i"
>>>         done
>>>         echo 'export
>>> PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$PATH'
>>> >> $script
>>> +       echo 'export
>>> CCACHE_PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$CCACHE_PATH'
>>> >> $script
>>>         echo 'export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT' >> $script
>>>         echo 'export
>>> PKG_CONFIG_PATH=$SDKTARGETSYSROOT'"$libdir"'/pkgconfig' >> $script
>>>         echo 'export
>>> CONFIG_SITE=${SDKPATH}/site-config-'"${multimach_target_sys}" >> $script
>>> @@ -37,6 +38,7 @@ toolchain_create_tree_env_script () {
>>>         rm -f $script
>>>         touch $script
>>>         echo 'export PATH=${STAGING_DIR_NATIVE}/usr/bin:${PATH}' >>
>>> $script
>>> +       echo 'export
>>> CCACHE_PATH=${STAGING_DIR_NATIVE}/usr/bin:${CCACHE_PATH}' >> $script
>>>         echo 'export PKG_CONFIG_SYSROOT_DIR=${PKG_CONFIG_SYSROOT_DIR}' >>
>>> $script
>>>         echo 'export PKG_CONFIG_PATH=${PKG_CONFIG_PATH}' >> $script
>>>         echo 'export CONFIG_SITE="${@siteinfo_get_files(d)}"' >> $script
>>>
>>
Otavio Salvador - Sept. 1, 2014, 6:04 p.m.
Laszlo,

On Mon, Sep 1, 2014 at 2:47 PM, Laszlo Papp <lpapp@kde.org> wrote:
> Just in case the severity is not clear. Without this change, the Yocto
> SDK breaks the build for our software since we do prefer to use ccache
> for speeding the build process up. We are probably not alone with that
> ...

Saul request is very valid. He is asking you to conform to the commit
guidelines we use and it is no-sense you to expect that he or someone
else does this for you.

So I think if you expect this to be merged you need to fix and send a v2.

Regards,
Fathi Boudra - Sept. 2, 2014, 6:22 a.m.
On 1 September 2014 21:04, Otavio Salvador <otavio@ossystems.com.br> wrote:
> Laszlo,
>
> On Mon, Sep 1, 2014 at 2:47 PM, Laszlo Papp <lpapp@kde.org> wrote:
>> Just in case the severity is not clear. Without this change, the Yocto
>> SDK breaks the build for our software since we do prefer to use ccache
>> for speeding the build process up. We are probably not alone with that
>> ...
>
> Saul request is very valid. He is asking you to conform to the commit
> guidelines we use and it is no-sense you to expect that he or someone
> else does this for you.
>
> So I think if you expect this to be merged you need to fix and send a v2.

fwiw, we've been hit by this maintainers behavior. Several patches are
stuck in the queue after 10 days of non-activity, followed up by a
nitpick comment.
It's a source of frustration for the submitter and is killing his
motivation. Such comment could come earlier, while he's in the heat of
the action and he's usually more receptive to the review.

As a result, we lose a contribution. The
project/maintainer/submitter/end-user doesn't benefit from the
contribution.

my 2cts.
Richard Purdie - Sept. 2, 2014, 7:11 a.m.
On Tue, 2014-09-02 at 09:22 +0300, Fathi Boudra wrote:
> On 1 September 2014 21:04, Otavio Salvador <otavio@ossystems.com.br> wrote:
> > Laszlo,
> >
> > On Mon, Sep 1, 2014 at 2:47 PM, Laszlo Papp <lpapp@kde.org> wrote:
> >> Just in case the severity is not clear. Without this change, the Yocto
> >> SDK breaks the build for our software since we do prefer to use ccache
> >> for speeding the build process up. We are probably not alone with that
> >> ...
> >
> > Saul request is very valid. He is asking you to conform to the commit
> > guidelines we use and it is no-sense you to expect that he or someone
> > else does this for you.
> >
> > So I think if you expect this to be merged you need to fix and send a v2.
> 
> fwiw, we've been hit by this maintainers behavior. Several patches are
> stuck in the queue after 10 days of non-activity, followed up by a
> nitpick comment.
> It's a source of frustration for the submitter and is killing his
> motivation. Such comment could come earlier, while he's in the heat of
> the action and he's usually more receptive to the review.
> 
> As a result, we lose a contribution. The
> project/maintainer/submitter/end-user doesn't benefit from the
> contribution.
> 
> my 2cts.

There are two sides to this. There can be frustrations on the submitters
side, equally, we don't have that many people prepared to review other
people's code. Code review is a pretty thankless task (as this thread is
showing) and trying to pull together all the different patches, testing
them and ensuring there are no regressions takes significant time and
effort.

In this case, the commit message does not match the guidelines. It is
not the reviewers responsibility to rewrite it so it does.

The other big problem that we see is that once a patch hits master, the
submitter considers their job done. If there are regressions found, we
sometimes see a "not my problem" attitude to getting those regressions
fixed. Obviously the change can be reverted but that has its own set of
problems too.

Personally speaking, I just do not have the time to try and do
everything I'd like to do. Ideally I'd read and reply to every patch in
real time with comprehensive review. For better or worse there are other
demands on my time (such as writing my own patches, mentoring others and
so on). This means I try and do an best effort and this applies to
others doing this work too. Even my best effort leaves me working crazy
hours and is actually likely having an effect on my health :(.

So I do regret people are frustrated, we doing the best we can with the
people available. If more people want to step up and help consolidate
patches that would be great but these kind of threads aren't going to
encourage it. 

The kernel gets around this by having subsystem maintainers. With
OE-Core, its certainly true that particular contributors do have
"ownership" of parts of the system in my mind and their changes to those
parts of the system are easier to review and accept. It would be good to
see more of that kind of ownership too but that trust takes time to
develop and its not something many are willing to work on. The layers
model obviously tries to help that too.

Cheers,

Richard
Paul Barker - Sept. 2, 2014, 9:03 a.m.
On Tue, Sep 02, 2014 at 08:11:05AM +0100, Richard Purdie wrote:
> On Tue, 2014-09-02 at 09:22 +0300, Fathi Boudra wrote:
> > On 1 September 2014 21:04, Otavio Salvador <otavio@ossystems.com.br> wrote:
> > > Laszlo,
> > >
> > > On Mon, Sep 1, 2014 at 2:47 PM, Laszlo Papp <lpapp@kde.org> wrote:
> > >> Just in case the severity is not clear. Without this change, the Yocto
> > >> SDK breaks the build for our software since we do prefer to use ccache
> > >> for speeding the build process up. We are probably not alone with that
> > >> ...
> > >
> > > Saul request is very valid. He is asking you to conform to the commit
> > > guidelines we use and it is no-sense you to expect that he or someone
> > > else does this for you.
> > >
> > > So I think if you expect this to be merged you need to fix and send a v2.
> > 
> > fwiw, we've been hit by this maintainers behavior. Several patches are
> > stuck in the queue after 10 days of non-activity, followed up by a
> > nitpick comment.
> > It's a source of frustration for the submitter and is killing his
> > motivation. Such comment could come earlier, while he's in the heat of
> > the action and he's usually more receptive to the review.
> > 
> > As a result, we lose a contribution. The
> > project/maintainer/submitter/end-user doesn't benefit from the
> > contribution.
> > 
> > my 2cts.
> 
> There are two sides to this. There can be frustrations on the submitters
> side, equally, we don't have that many people prepared to review other
> people's code. Code review is a pretty thankless task (as this thread is
> showing) and trying to pull together all the different patches, testing
> them and ensuring there are no regressions takes significant time and
> effort.
> 

Obvious style issues as this patch had don't require someone to be an expert on
the area of the code that has been changed in order to give a review. I'm happy
to keep my eyes open and try to comment where something doesn't match the patch
guidelines and a few more people doing that would catch the low hanging fruit at
least.

> 
> The kernel gets around this by having subsystem maintainers. With
> OE-Core, its certainly true that particular contributors do have
> "ownership" of parts of the system in my mind and their changes to those
> parts of the system are easier to review and accept. It would be good to
> see more of that kind of ownership too but that trust takes time to
> develop and its not something many are willing to work on. The layers
> model obviously tries to help that too.
> 

Ownership like this is excellent. What would help the most is a simple tool or
method to tell you who to Cc on a patch when you send it to the mailing list.
Linux has the "get_maintainer.pl" script for this. I haven't seen anything
similar in oe-core.

For example, I'd like to be Cc'd on changes to opkg in oe-core and vim in
meta-oe as I know those recipes well. I wouldn't expect people to wait for my
review, but a Cc might speed things up. I often miss patches to the areas I'm
interested in if I'm too busy to follow the mailing lists in detail.

Thanks,
Laszlo Papp - Sept. 9, 2014, 3:02 p.m.
On Tue, Sep 2, 2014 at 7:22 AM, Fathi Boudra <fathi.boudra@linaro.org> wrote:
> On 1 September 2014 21:04, Otavio Salvador <otavio@ossystems.com.br> wrote:
>> Laszlo,
>>
>> On Mon, Sep 1, 2014 at 2:47 PM, Laszlo Papp <lpapp@kde.org> wrote:
>>> Just in case the severity is not clear. Without this change, the Yocto
>>> SDK breaks the build for our software since we do prefer to use ccache
>>> for speeding the build process up. We are probably not alone with that
>>> ...
>>
>> Saul request is very valid. He is asking you to conform to the commit
>> guidelines we use and it is no-sense you to expect that he or someone
>> else does this for you.
>>
>> So I think if you expect this to be merged you need to fix and send a v2.
>
> fwiw, we've been hit by this maintainers behavior. Several patches are
> stuck in the queue after 10 days of non-activity, followed up by a
> nitpick comment.
> It's a source of frustration for the submitter and is killing his
> motivation. Such comment could come earlier, while he's in the heat of
> the action and he's usually more receptive to the review.
>
> As a result, we lose a contribution. The
> project/maintainer/submitter/end-user doesn't benefit from the
> contribution.
>
> my 2cts.

Thanks for trying to get things done, Fathi. I appreciate it. I also
understand what Richard was writing that they are busy. Sure, I am
very busy, too, but not helping others to get involved easily will
leave more burden on them in the long run, sadly.

This is not the first time that I have to follow changes for
relatively long time, and the patch in the end does not get in, even
when it fails build failures for end users, like this one.

The last long bikeshed was around the busybox-ntp. Since I keep
patching our Yocto fork, I thought after a while, let us give it a try
again with a simple thing, and it went as far as this, only after
follow-ups 1-2 weeks later.

It is probably needless to say, but I feel personally very difficult
to get involved in the Yocto project and I am not saying it because
there are cosmetic changes with my patches. That is a good level if it
is just cosmetic in a newcomer's patch anyway?

I am just trying to write that as someone who is working for a very
small company, I do not have time for all superfluous perfectionism
this project tries to follow. I appreciate, but I cannot cope with it.
My highest responsibility is to get things done and ship products.
That does not include cosmetic nitpicking in a small company. It might
be OK for Google, Intel, Linux Foundation, etc, but this is simply not
any priority when you need to work on getting proper income for your
family.

Why I am personally a little bit frustrated unfortunately it is not
because things like this happen, but that it happens in a row. The
Yocto users are still screwed for using ntp properly with busybox.
That change also went to /dev/null due to some irrelevant thing. What
is worse, someone even wrote me in person that it is a shame it did
not get in since that person would have also needed the feature.

As far as I am concerned, the Yocto project contribution is currently
unsuitable for small companies and individuals whose highest
responsibility is to get income, i.e. caring about sustainable
features rather than nitpicks. I have been on both sides, and I can
understand when someone is maximalist. It is very difficult to
understand others in the state of mind; been there, done that.

Anyway, I have a relatively long list of unintegrated features into
Yocto by now, but this is not quite good that they are going on their
own way in a fork rather than going in. As it was written in this
thread, it is quite demotivating to see such nitpicks after 1-2 weeks,
and then long discussions about who is doing what. I can assure you
that if I had not had several changes rejected due to such nitpicks, I
would have already fixed this one, but in this case, I am not doing
them anymore since I do not see any willingness from the Yocto
community to try to help me with getting things easily in.

Patch

diff --git a/meta/classes/toolchain-scripts.bbclass b/meta/classes/toolchain-scripts.bbclass
index 6cc8eba..60278d6 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -19,6 +19,7 @@  toolchain_create_sdk_env_script () {
 		EXTRAPATH="$EXTRAPATH:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_ARCH}${TARGET_VENDOR}-$i"
 	done
 	echo 'export PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$PATH' >> $script
+	echo 'export CCACHE_PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$CCACHE_PATH' >> $script
 	echo 'export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT' >> $script
 	echo 'export PKG_CONFIG_PATH=$SDKTARGETSYSROOT'"$libdir"'/pkgconfig' >> $script
 	echo 'export CONFIG_SITE=${SDKPATH}/site-config-'"${multimach_target_sys}" >> $script
@@ -37,6 +38,7 @@  toolchain_create_tree_env_script () {
 	rm -f $script
 	touch $script
 	echo 'export PATH=${STAGING_DIR_NATIVE}/usr/bin:${PATH}' >> $script
+	echo 'export CCACHE_PATH=${STAGING_DIR_NATIVE}/usr/bin:${CCACHE_PATH}' >> $script
 	echo 'export PKG_CONFIG_SYSROOT_DIR=${PKG_CONFIG_SYSROOT_DIR}' >> $script
 	echo 'export PKG_CONFIG_PATH=${PKG_CONFIG_PATH}' >> $script
 	echo 'export CONFIG_SITE="${@siteinfo_get_files(d)}"' >> $script