[Buildroot] [PATCH v2] Enable ccache for cmake packages

[Samuel Martin]

Hi Lucas, all,

2013/3/28 Luca Ceresoli <luca at lucaceresoli.net>:
[...]
> If you add at the beginning of toolchainfile.cmake the line:
> message("USE_CCACHE=${USE_CCACHE}")
> and then run `make rpi-userland{-dirclean,}` you'll see:
>
[...]
>
> Apparently CMake interprets multiple times the toolchainfile.cmake,
> and it does not always pass the original parameters, so USE_CCACHE is
> sometimes undefined. Hence my idea to handle that variable as a
> tristate.
>

I don't know that much about CMake innards, but i'm pretty sure, in
the end, it is what is set in the CMakeCache.txt file that is used.


>
>> Now, I got it, but I'm really dubious about behavior in the last case.
>>
>> I mean: the goal of this toolchainfile.cmake is, among other thing, to
>> be able to reuse the Buildroot toolchain
>> to build a projects outside Buildroot because CMake is good at this.
>>
>> So, in that case, we want to be sure we correctly export the toolchain
>> properties.
>>
>> If we don't set any compiler in the case USE_CCACHE is undefined, then
>> we totally miss this goal,
>> and IMHO, it does not make sense because the toolchainfile.cmake file
>> is generated by Buildroot,
>> for the Buildroot toolchain and nothing else.
>
>
> I actually overlookedthe need to make the whole thing usable from
> outside Buildroot. It should be made working indeed.
>
>
>> Maybe the logic is a bit more complex... something like that:
>>
>> set(FIND_PROGRAM_PATH "$(HOST_DIR)/usr/bin")
>> find_program(CCACHE "ccache")
>> if (DEFINED USE_CCACHE)
>>    if (USE_CCACHE AND CCACHE)
>>      # set the compiler variables with ccache support
>>    else ()
>>      # set the compiler variables without ccache support
>>    endif ()
>> else ()
>>    message("To enable ccache usage, add -DUSE_CACHE=ON on the command
>> line")
>>    # fallback: set only the compiler variables (with no ccache support)
>> endif ()
>
>
> I don't like very much automagic things, such as using a tool
> transparently when it'sfound. We have a BR2_CCACHE config knob, that
> should rule IMO.

An alternative, with no magics when used by Buildroot:

In the CONFIGURE_CMDS functions in pkg-cmake, add -DCCACHE="$(CCACHE)",
then, in the toolchainfile.cmake:

---
set(FIND_PROGRAM_PATH "$(HOST_DIR)/usr/bin")

if(DEFINED CCACHE) # check if run by buildroot.
  # Note that to make it very cristal and enforce this check, we can
use the following condition:
  # if(DEFINED CCACHE AND NOT "$ENV{BR2_VERSION}" STREQUAL "")
  #
  # Run inside buildroot
  if (DEFINED USE_CCACHE NOT "${CCACHE}" STREQUAL "")
    # set the compiler variables with ccache support
  else ()
    # set the compiler variables without ccache support
  endif ()
else ()
  # Run outside buildroot
  if (DEFINED USE_CCACHE)
    # ccache support is set
    if (USE_CCACHE)
      # ccache support is requested
      find_program(CCACHE "ccache")
      if(CCACHE)
        # ccache support is available
        # set the compiler variables with ccache support
      else ()
        # ccache support is not available
        message("No ccache binary found")
        # set the compiler variables without ccache support
      endif ()
    else ()
      # ccache support is explicitly disabled
      # set the compiler variables without ccache support
    endif ()
  else ()
    # ccache support is undefined
    message("To enable ccache usage, add -DUSE_CACHE=ON on the command line")
    # fallback: set only the compiler variables (with no ccache support)
  endif ()
endif ()
---

>
> Still, yours is an interesting proposal. The only alternative is
> probably to put the ccachelogic in the wrappers as Thomas proposed in
> reply to my v1 patch.
>
> But I see a problem here: Buildroot exports BUILDROOT_CACHE_DIR, and
> $(HOST_DIR)/usr/bin/ccacheuses that environment variable to locate its
> cache directory. If the same ccache executable is executed standalone
> it does won't find that environment variable and default to ~/.ccache.

Is that a problem to fallback on ~/.ccache when used outside Buildroot?

BTW, if you really want to reuse the Buildroot ccache directory, you can add:

---
if(DEFINED CCACHE_DIR)
  set(ENV{BUILDROOT_CACHE_DIR} "${CCACHE_DIR}")
else()
  message("Using the default ccache directory.")
  message("To use an alternative ccache directory, add
-DCCACHE_DIR=/path/to/somewhere")
endif()
---

>
> Anyway, thinking more about how to implement this feature, I think
> maybe Thomas' proposal can avoid the mentioned issues, as the call to
> ccache (as well as the ccache directory path) can be coded inside a
> (C?) wrapper if the wrapper has been built with BR2_CCACHE=y.
> But we would need to regenerate the wrapper whenever the user changes
> the BR2_CCACHE...
>
> Also, the BR-built ccache would be used transparently even when
> calling ${HOST_DIR}/usr/bin/*-gcc. This shows clearly an advantage,
> although the user might not understand well that he's using ccache
> under the hood (maybe not a problem).
>
> But I'd like to understand better your idea, Thomas.
Me too, though I'm not so fond of wrappers...

> The ccache
> usage is independent from the toolchain type (Buildroot/ct-NG/
> external).  Would you implement a unique wrapper to be used for
> all three toolchain types, and replace the current
> ext-toolchain-wrapper.c?
>
> Luca
>

Regards,

-- 
Samuel