[Buildroot] ccache problem when compiling with different toolchains in different projects

[Buildroot] ccache problem when compiling with different toolchains in different projects

[Danomi Manchego]

All,

Let me preface this by saying that I know that we are supposed to manually
flush the ccache when changing toolchain configuration.  This post is not
about that (I think) - it's about building different configurations, in
different locations, on the same machine.  (Emphasis on "in different
locations".)

Recently, I found a case where ccache was being fooled during the building
of kmod (a dependency of udev), in the following circumstance:

1. I compiled buildroot with O=cs2012, with a downloaded codesourcery
2012.03 toolchain.

   Defconfig:
      BR2_arm=y
      BR2_CCACHE=y
      BR2_TOOLCHAIN_EXTERNAL=y
      BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
      BR2_PACKAGE_KMOD=y

2. I attempted to compile buildroot with O=cs2009, with a pre-installed
codesourcery 2009q1 toolchain

   Defconfig:
      BR2_arm=y
      BR2_CCACHE=y
      BR2_TOOLCHAIN_EXTERNAL=y
      BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y

BR2_TOOLCHAIN_EXTERNAL_PATH="/opt/codesourcery/arm-2009q1-203-arm-none-linux-gnueabi"
      BR2_TOOLCHAIN_EXTERNAL_CUSTOM_PREFIX="arm-none-linux-gnueabi"
      BR2_TOOLCHAIN_EXTERNAL_CUSTOM_GLIBC=y
      BR2_TOOLCHAIN_EXTERNAL_CXX=y
      BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
      BR2_PACKAGE_KMOD=y

3. Then kmod build failed, due to "Unknown mandatory EABI object attribute
44".

After examining ccache stats at each stage, I think what is happening is
that when the compile line has only relative paths, and hashing on the
compiler itself is disabled (as it is in buildroot's build of ccache), then
the compile under the cs2009 directory cannot be distinguished from the
compile in the cs2012 directory (i.e., the computed hash values are
identical), so the cs2012 objects are used, leading to disaster.

Another variation occurred when I compiled first using a 2010q1 cs
toolchain (O=cs2010), which supports -Wno-unsused-result, followed by
2009q1, which does not.  When configure compiled its little programs to
test the c-flags in cs2009, it pulled cs2010's object, and erroneously
concluded that -Wno-unsused-result was supported.  The compile of the
actual kmod source with -Wno-unsused-result then failed.

As it turns out, ccache will include the current directory in the hash when
the environment variable CCACHE_HASHDIR is defined.  I have confirmed that
defining CCACHE_HASHDIR makes the above scenario compile correctly -
different files get cached for the cs2012 and cs2009 builds, since the
source files live in different locations.  So I think that I will probably
force the behavior activated by CCACHE_HASHDIR for our project - similar to
how the CCACHE_COMPILERCHECK selection is forced to "none".

If others think that this is a good idea, then I would be happy to submit a
patch to this effect.

Danomi -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130418/1052814f/attachment.html>

[Buildroot] ccache problem when compiling with different toolchains in different projects

[Mathias De Maré]

Hello,

wouldn't an alternative possibility be to change the CCACHE_COMPILERCHECK
to:
export CCACHE_COMPILERCHECK=%compiler% -v

You don't rely on the timestamp that way, but you still have a check. I
believe this resolves the clearing of ccache also (see also
http://lists.busybox.net/pipermail/buildroot/2012-March/051187.html ).

For my host gcc, this gives:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --enable-plugin --enable-objc-gc
--disable-werror --with-arch-32=i686 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)

Greetings,
Mathias



On Fri, Apr 19, 2013 at 3:50 AM, Danomi Manchego <
danomimanchego123@gmail.com> wrote:

> All,
>
> Let me preface this by saying that I know that we are supposed to manually
> flush the ccache when changing toolchain configuration.  This post is not
> about that (I think) - it's about building different configurations, in
> different locations, on the same machine.  (Emphasis on "in different
> locations".)
>
> Recently, I found a case where ccache was being fooled during the building
> of kmod (a dependency of udev), in the following circumstance:
>
> 1. I compiled buildroot with O=cs2012, with a downloaded codesourcery
> 2012.03 toolchain.
>
>    Defconfig:
>       BR2_arm=y
>       BR2_CCACHE=y
>       BR2_TOOLCHAIN_EXTERNAL=y
>       BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
>       BR2_PACKAGE_KMOD=y
>
> 2. I attempted to compile buildroot with O=cs2009, with a pre-installed
> codesourcery 2009q1 toolchain
>
>    Defconfig:
>       BR2_arm=y
>       BR2_CCACHE=y
>       BR2_TOOLCHAIN_EXTERNAL=y
>       BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
>
> BR2_TOOLCHAIN_EXTERNAL_PATH="/opt/codesourcery/arm-2009q1-203-arm-none-linux-gnueabi"
>       BR2_TOOLCHAIN_EXTERNAL_CUSTOM_PREFIX="arm-none-linux-gnueabi"
>       BR2_TOOLCHAIN_EXTERNAL_CUSTOM_GLIBC=y
>       BR2_TOOLCHAIN_EXTERNAL_CXX=y
>       BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
>       BR2_PACKAGE_KMOD=y
>
> 3. Then kmod build failed, due to "Unknown mandatory EABI object attribute
> 44".
>
> After examining ccache stats at each stage, I think what is happening is
> that when the compile line has only relative paths, and hashing on the
> compiler itself is disabled (as it is in buildroot's build of ccache), then
> the compile under the cs2009 directory cannot be distinguished from the
> compile in the cs2012 directory (i.e., the computed hash values are
> identical), so the cs2012 objects are used, leading to disaster.
>
> Another variation occurred when I compiled first using a 2010q1 cs
> toolchain (O=cs2010), which supports -Wno-unsused-result, followed by
> 2009q1, which does not.  When configure compiled its little programs to
> test the c-flags in cs2009, it pulled cs2010's object, and erroneously
> concluded that -Wno-unsused-result was supported.  The compile of the
> actual kmod source with -Wno-unsused-result then failed.
>
> As it turns out, ccache will include the current directory in the hash
> when the environment variable CCACHE_HASHDIR is defined.  I have confirmed
> that defining CCACHE_HASHDIR makes the above scenario compile correctly -
> different files get cached for the cs2012 and cs2009 builds, since the
> source files live in different locations.  So I think that I will probably
> force the behavior activated by CCACHE_HASHDIR for our project - similar to
> how the CCACHE_COMPILERCHECK selection is forced to "none".
>
> If others think that this is a good idea, then I would be happy to submit
> a patch to this effect.
>
> Danomi -
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130419/92a3a7a5/attachment.html>

[Buildroot] ccache problem when compiling with different toolchains in different projects

[Arnout Vandecappelle]

On 19/04/13 13:41, Mathias De Mar? wrote:
>
> wouldn't an alternative possibility be to change the CCACHE_COMPILERCHECK to:
> export CCACHE_COMPILERCHECK=%compiler% -v
>
> You don't rely on the timestamp that way, but you still have a check. I
> believe this resolves the clearing of ccache also (see also
> http://lists.busybox.net/pipermail/buildroot/2012-March/051187.html ).

  That sounds like a very good idea!

  It still has a few shortcomings, but it's definitely better than the 
current situation. At least the following are not solved yet.

- Options included in the external toolchain wrapper are not included. 
For instance, if you switch to Thumb on the Sourcery ARM toolchain, that 
will be recorded in the additional cflags in the wrapper and won't be 
visible to ccache.

- The output of gcc -v contains the absolute path, so if you change the 
output directory (or share the ccache between several developers) it 
won't work. But it would be feasible to strip off the $(O) part.

- For internal/crosstool-NG toolchains, when toolchain parameters are 
changed this is still not detected. For instance, some configure script 
checks for wchar, it fails, you change your configuration to include 
WCHAR and rebuild, and it still fails because the cached test is used...


  The ideal is still what I mentioned a year ago [1]: make a hash of the 
toolchain configuration part of the buildroot config. Too complex, unless 
we do a big rename of the relevant options into BR2_TOOLCHAIN_...
and grep them out of the config.


  Regards,
  Arnout


[1]
    http://lists.busybox.net/pipermail/buildroot/2012-February/049998.html

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] ccache problem when compiling with different toolchains in different projects

[Danomi Manchego]

On Fri, Apr 19, 2013 at 4:54 PM, Arnout Vandecappelle <arnout@mind.be>wrote:

> On 19/04/13 13:41, Mathias De Mar? wrote:
>
>>
>> wouldn't an alternative possibility be to change the CCACHE_COMPILERCHECK
>> to:
>> export CCACHE_COMPILERCHECK=%**compiler% -v
>>
>> You don't rely on the timestamp that way, but you still have a check. I
>> believe this resolves the clearing of ccache also (see also
>> http://lists.busybox.net/**pipermail/buildroot/2012-**March/051187.html<http://lists.busybox.net/pipermail/buildroot/2012-March/051187.html>).
>>
>
>  That sounds like a very good idea!
>
>  It still has a few shortcomings, but it's definitely better than the
> current situation. At least the following are not solved yet.
>
> - Options included in the external toolchain wrapper are not included. For
> instance, if you switch to Thumb on the Sourcery ARM toolchain, that will
> be recorded in the additional cflags in the wrapper and won't be visible to
> ccache.
>
> - The output of gcc -v contains the absolute path, so if you change the
> output directory (or share the ccache between several developers) it won't
> work. But it would be feasible to strip off the $(O) part.
>
> - For internal/crosstool-NG toolchains, when toolchain parameters are
> changed this is still not detected. For instance, some configure script
> checks for wchar, it fails, you change your configuration to include WCHAR
> and rebuild, and it still fails because the cached test is used...
>


I think that the "%**compiler% -v" suggestion is definitely more robust
that the current "none" setting, and my CCACHE_HASHDIR idea.  Glad I asked!

Regarding the settings hidden by the ext-toolchan wrapper and the built
toolchain configuration options - what if we took a hash of the
ext-toolchain wrapper or built compiler itself, and the -v info, and used
that directly in the ccache check.  We could do a one-time hash when the
toolchain is set up:

    $(TARGET_CC_NOCCACHE) -v > $(STAMP_DIR)/toolchain-config-info
    md5sum -b $(TARGET_CC_NOCCACHE) >> $(STAMP_DIR)/toolchain-config-info
    md5sum $(STAMP_DIR)/toolchain-config-info >
$(STAMP_DIR)/toolchain-config-info.md5sum

and then set the CCACHE_COMPILERCHECK to "echo
$(STAMP_DIR)/toolchain-config-info.md5sum".  Then, the effects of all the
hidden variables are in some way accounted for without grepping for them in
the .config.

Is that crazy talk?

Danomi -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130419/0da6ec47/attachment.html>

[Buildroot] ccache problem when compiling with different toolchains in different projects

[Danomi Manchego]

> and then set the CCACHE_COMPILERCHECK to "echo
> $(STAMP_DIR)/toolchain-config-info.md5sum".  Then, the effects of all the
> hidden variables are in some way accounted for without grepping for them in
> the .config.\
>

Sorry, that should have been "cat", not "echo"  - as in 'set the
CCACHE_COMPILERCHECK to "cat $(STAMP_DIR)/toolchain-config-info.md5sum" '.

Danomi -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130419/391736e2/attachment.html>

[Buildroot] ccache problem when compiling with different toolchains in different projects

[Arnout Vandecappelle]

On 20/04/13 01:00, Danomi Manchego wrote:
[snip]
> Regarding the settings hidden by the ext-toolchan wrapper and the built
> toolchain configuration options - what if we took a hash of the
> ext-toolchain wrapper or built compiler itself, and the -v info, and used
> that directly in the ccache check.  We could do a one-time hash when the
> toolchain is set up:
>
>      $(TARGET_CC_NOCCACHE) -v > $(STAMP_DIR)/toolchain-config-info
>      md5sum -b $(TARGET_CC_NOCCACHE) >> $(STAMP_DIR)/toolchain-config-info
>      md5sum $(STAMP_DIR)/toolchain-config-info >
> $(STAMP_DIR)/toolchain-config-info.md5sum

  Not bad! I'd still sed the absolute path out of the 'gcc -v' output, 
though. Then at least with external toolchains you can share the ccache 
between different developers (and an external toolchain is anyway the way 
to go if you want to speed up build time).

> and then set the CCACHE_COMPILERCHECK to "echo
> $(STAMP_DIR)/toolchain-config-info.md5sum".

  The name of the compiler should also be included. gcc compiles 'void 
main () {}' differently than g++.

  BTW it could be optimized a little more by putting the hash in a make 
variable and echo'ing that directly.


> Then, the effects of all the
> hidden variables are in some way accounted for without grepping for them
> in the .config.

  Not entirely. Many toolchain options affect the C library, not the 
compiler. A change in these options may not affect the gcc binary itself. 
Even a gcc configuration option may not change the gcc binary, because 
most of gcc is in cc1 and libgcc.a. But it's still an improvement over 
previous proposals.

  Regards,
  Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] ccache problem when compiling with different toolchains in different projects

[Danomi Manchego]

On Fri, Apr 19, 2013 at 7:41 PM, Arnout Vandecappelle <arnout@mind.be>wrote:

>  Then, the effects of all the
>> hidden variables are in some way accounted for without grepping for them
>> in the .config.
>>
>
>  Not entirely. Many toolchain options affect the C library, not the
> compiler. A change in these options may not affect the gcc binary itself.
> Even a gcc configuration option may not change the gcc binary, because most
> of gcc is in cc1 and libgcc.a. But it's still an improvement over previous
> proposals.
>

Arnout, I'm wavering on this.

At work, we only use external toolchains (downloaded or pre-installed), so
using the gcc -v output and the md5sum of the compiler/wrapper provided to
ccache is perfect for our projects, because these discriminators capture
everything.  But if toolchain configuration options in the general case
(for everyone else) cannot be simply captured (without doing lots of
variable renaming as you mentioned earlier), then it seems to me that
buildroot's official position must remain that the user must know when to
flush the cache, and do it manually.  What was not clear to me before is
that I have to not only keep in mind my build configuration, but also the
configuration of every other buildroot build on the machine, whether it's
mine or somebody else's.  In light of that, would it not be better to limit
the scope of self-policing to just the area you are working in, by
including absolute paths (in the COMPILERCHECK, or HASHDIR) to disable
sharing cached objects when you change output directories, or between
several developers?  It's bad enough to have to remember to flush the cache
based our our own activities, but it truly stinks to have to defend against
getting screwed up by somebody else's build.

I'm just trying to think this through from a community perspective ...

Danomi -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130420/1725bbb1/attachment.html>

[Buildroot] ccache problem when compiling with different toolchains in different projects

[Mathias De Maré]

On Sat, Apr 20, 2013 at 6:08 PM, Danomi Manchego <
danomimanchego123@gmail.com> wrote:

> On Fri, Apr 19, 2013 at 7:41 PM, Arnout Vandecappelle <arnout@mind.be>wrote:
>
>  Then, the effects of all the
>>> hidden variables are in some way accounted for without grepping for them
>>> in the .config.
>>>
>>
>>  Not entirely. Many toolchain options affect the C library, not the
>> compiler. A change in these options may not affect the gcc binary itself.
>> Even a gcc configuration option may not change the gcc binary, because most
>> of gcc is in cc1 and libgcc.a. But it's still an improvement over previous
>> proposals.
>>
>
> Arnout, I'm wavering on this.
>
> At work, we only use external toolchains (downloaded or pre-installed), so
> using the gcc -v output and the md5sum of the compiler/wrapper provided to
> ccache is perfect for our projects, because these discriminators capture
> everything.  But if toolchain configuration options in the general case
> (for everyone else) cannot be simply captured (without doing lots of
> variable renaming as you mentioned earlier), then it seems to me that
> buildroot's official position must remain that the user must know when to
> flush the cache, and do it manually.  What was not clear to me before is
> that I have to not only keep in mind my build configuration, but also the
> configuration of every other buildroot build on the machine, whether it's
> mine or somebody else's.  In light of that, would it not be better to limit
> the scope of self-policing to just the area you are working in, by
> including absolute paths (in the COMPILERCHECK, or HASHDIR) to disable
> sharing cached objects when you change output directories, or between
> several developers?  It's bad enough to have to remember to flush the cache
> based our our own activities, but it truly stinks to have to defend against
> getting screwed up by somebody else's build.
>
> I'm just trying to think this through from a community perspective ...
>

Very good point, Danomi.

One of the most important points about ccache is it being safe (no
incorrect behaviour) *. If this is not possible, it should at least be 'as
safe as possible', so be separate per buildroot build. It would be nice if
it were possible though: it could result in a big gain.

*Note: this is also why I, for a large project, use 'CCACHE_NODIRECT'. See
also: https://bugzilla.samba.org/show_bug.cgi?id=8424

Greetings,
Mathias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130421/d525b2d6/attachment.html>

[Buildroot] ccache problem when compiling with different toolchains in different projects

[Arnout Vandecappelle]

On 20/04/13 18:08, Danomi Manchego wrote:
> On Fri, Apr 19, 2013 at 7:41 PM, Arnout Vandecappelle <arnout@mind.be
> <mailto:arnout@mind.be>> wrote:
>
>         Then, the effects of all the
>         hidden variables are in some way accounted for without grepping
>         for them
>         in the .config.
>
>
>       Not entirely. Many toolchain options affect the C library, not the
>     compiler. A change in these options may not affect the gcc binary
>     itself. Even a gcc configuration option may not change the gcc
>     binary, because most of gcc is in cc1 and libgcc.a. But it's still an
>     improvement over previous proposals.
>
>
> Arnout, I'm wavering on this.
>
> At work, we only use external toolchains (downloaded or pre-installed),
> so using the gcc -v output and the md5sum of the compiler/wrapper
> provided to ccache is perfect for our projects, because
> these discriminators capture everything.  But if toolchain configuration
> options in the general case (for everyone else) cannot be simply captured
> (without doing lots of variable renaming as you mentioned earlier),

  Actually, after thinking a bit harder about it: the following should work:

sed -n '/^# Toolchain/,/^# System configuration/' $(BUILDROOT_CONFIG) \
	| md5sum -

  So there's no need to rename stuff or anything.

> then
> it seems to me that buildroot's official position must remain that the
> user must know when to flush the cache, and do it manually.

  I personally find that a very weak position, so anything we can do to 
remove that limitation is not just good, but a must. Note BTW that the 
documentation makes no mention of the need to clear ccache when you 
change the toolchain.

> What was not
> clear to me before is that I have to not only keep in mind my build
> configuration, but also the configuration of every other buildroot build
> on the machine, whether it's mine or somebody else's.

  The 'somebody else's' is only true if you explicitly share your ccache 
by setting BR2_CCACHE_DIR to a shared directory.


  Regards,
  Arnout

>  In light of that,
> would it not be better to limit the scope of self-policing to just the
> area you are working in, by including absolute paths (in the
> COMPILERCHECK, or HASHDIR) to disable sharing cached objects when you
> change output directories, or between several developers?  It's bad
> enough to have to remember to flush the cache based our our own
> activities, but it truly stinks to have to defend against getting screwed
> up by somebody else's build.
>
> I'm just trying to think this through from a community perspective ...
>
> Danomi -
>


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] ccache problem when compiling with different toolchains in different projects

[Danomi Manchego]

On Mon, Apr 22, 2013 at 1:59 AM, Arnout Vandecappelle <arnout@mind.be>wrote:

> On 20/04/13 18:08, Danomi Manchego wrote:
>
>> On Fri, Apr 19, 2013 at 7:41 PM, Arnout Vandecappelle <arnout@mind.be
>> <mailto:arnout@mind.be>> wrote:
>>
>>         Then, the effects of all the
>>         hidden variables are in some way accounted for without grepping
>>         for them
>>         in the .config.
>>
>>
>>       Not entirely. Many toolchain options affect the C library, not the
>>     compiler. A change in these options may not affect the gcc binary
>>     itself. Even a gcc configuration option may not change the gcc
>>     binary, because most of gcc is in cc1 and libgcc.a. But it's still an
>>     improvement over previous proposals.
>>
>>
>> Arnout, I'm wavering on this.
>>
>> At work, we only use external toolchains (downloaded or pre-installed),
>> so using the gcc -v output and the md5sum of the compiler/wrapper
>> provided to ccache is perfect for our projects, because
>> these discriminators capture everything.  But if toolchain configuration
>> options in the general case (for everyone else) cannot be simply captured
>> (without doing lots of variable renaming as you mentioned earlier),
>>
>
>  Actually, after thinking a bit harder about it: the following should work:
>
> sed -n '/^# Toolchain/,/^# System configuration/' $(BUILDROOT_CONFIG) \
>         | md5sum -
>
>  So there's no need to rename stuff or anything.


That would also use the GDB and ECLIPSE lines too.  But then, if it
accounts for everything outside of the "%compiler% -v" info (wrappers,
C-library), then it's worth it.

I suppose that we could drop the these lines with an inverse grep:

sed -n '/^# Toolchain/,/^# System configuration/p' .config | \
    grep -v -e '^#' -e GDG -e ECLIPSE | \
    md5sum

Too much?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130422/75eb3c53/attachment.html>

[Buildroot] ccache problem when compiling with different toolchains in different projects

[Arnout Vandecappelle]

On 22/04/13 14:32, Danomi Manchego wrote:
> On Mon, Apr 22, 2013 at 1:59 AM, Arnout Vandecappelle <arnout@mind.be
> <mailto:arnout@mind.be>> wrote:
[snip]
>       Actually, after thinking a bit harder about it: the following
>     should work:
>
>     sed -n '/^# Toolchain/,/^# System configuration/' $(BUILDROOT_CONFIG) \
>              | md5sum -
>
>       So there's no need to rename stuff or anything.
>
>
> That would also use the GDB and ECLIPSE lines too.  But then, if it
> accounts for everything outside of the "%compiler% -v" info (wrappers,
> C-library), then it's worth it.
>
> I suppose that we could drop the these lines with an inverse grep:
>
> sed -n '/^# Toolchain/,/^# System configuration/p' .config | \
>      grep -v -e '^#' -e GDG -e ECLIPSE | \
>      md5sum
>
> Too much?

  Too much, yes :-) But perhaps we could change the order of the 
toolchain options.

  Regards,
  Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] ccache problem when compiling with different toolchains in different projects

[Thomas De Schampheleire]

On Mon, Apr 22, 2013 at 11:26 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 22/04/13 14:32, Danomi Manchego wrote:
>>
>> On Mon, Apr 22, 2013 at 1:59 AM, Arnout Vandecappelle <arnout@mind.be
>> <mailto:arnout@mind.be>> wrote:
>
> [snip]
>
>>       Actually, after thinking a bit harder about it: the following
>>     should work:
>>
>>     sed -n '/^# Toolchain/,/^# System configuration/' $(BUILDROOT_CONFIG)
>> \
>>              | md5sum -
>>
>>       So there's no need to rename stuff or anything.
>>
>>
>> That would also use the GDB and ECLIPSE lines too.  But then, if it
>> accounts for everything outside of the "%compiler% -v" info (wrappers,
>> C-library), then it's worth it.
>>
>> I suppose that we could drop the these lines with an inverse grep:
>>
>> sed -n '/^# Toolchain/,/^# System configuration/p' .config | \
>>      grep -v -e '^#' -e GDG -e ECLIPSE | \
>>      md5sum
>>
>> Too much?
>
>
>  Too much, yes :-) But perhaps we could change the order of the toolchain
> options.
>

Reviving this thread...
http://lists.busybox.net/pipermail/buildroot/2013-April/070819.html

Is there any specific reason why there was no further evolution on this?

Best regards,
Thomas

[Buildroot] ccache problem when compiling with different toolchains in different projects

[Danomi Manchego]

Thomas,

On Thu, Oct 24, 2013 at 6:31 AM, Thomas De Schampheleire
<patrickdepinguin+buildroot@gmail.com> wrote:
> On Mon, Apr 22, 2013 at 11:26 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
>> On 22/04/13 14:32, Danomi Manchego wrote:
>>>
>>> On Mon, Apr 22, 2013 at 1:59 AM, Arnout Vandecappelle <arnout@mind.be
>>> <mailto:arnout@mind.be>> wrote:
>>
>> [snip]
>>
>>>       Actually, after thinking a bit harder about it: the following
>>>     should work:
>>>
>>>     sed -n '/^# Toolchain/,/^# System configuration/' $(BUILDROOT_CONFIG)
>>> \
>>>              | md5sum -
>>>
>>>       So there's no need to rename stuff or anything.
>>>
>>>
>>> That would also use the GDB and ECLIPSE lines too.  But then, if it
>>> accounts for everything outside of the "%compiler% -v" info (wrappers,
>>> C-library), then it's worth it.
>>>
>>> I suppose that we could drop the these lines with an inverse grep:
>>>
>>> sed -n '/^# Toolchain/,/^# System configuration/p' .config | \
>>>      grep -v -e '^#' -e GDG -e ECLIPSE | \
>>>      md5sum
>>>
>>> Too much?
>>
>>
>>  Too much, yes :-) But perhaps we could change the order of the toolchain
>> options.
>>
>
> Reviving this thread...
> http://lists.busybox.net/pipermail/buildroot/2013-April/070819.html
>
> Is there any specific reason why there was no further evolution on this?

The conversation was dropped on my end because I actually came up with
a mod to ccache.mk as described above (GDB and ECPLIPSE filter
included), and have been using it ever since.  (Initially "testing",
of course, then just forgotten.)

I didn't submit a patch because the "%compiler% -v" portion of the
additional hash content could have the effect of introducing a path to
the individual's build directory (for built toolchains, I think - I
only use external or downloaded toolchains, so not sure) - which would
be bad for groups that use a shared cache directory.

But if you like, I can separate my ccache.mk changes into two or three
patches (since I did a couple other things too), and send as RFC.  But
I don't have too much time to do rework for the built toolchains.

Danomi -