[CMake] CCACHE_DIR Environment Variable

Craig Scott craig.scott at crascit.com
Tue Jan 31 17:34:58 EST 2017


On Wed, Feb 1, 2017 at 8:57 AM, David Lind <davidklind at gmail.com> wrote:

> The example shown on https://crascit.com/2016/
> 04/09/using-ccache-with-cmake/ is for Xcode. Hence setting the
> CMAKE_XCODE_ATTRIBUTE… variables. On Linux, what are these variables? Are
> they CMAKE_ATTRIBUTE… without XCODE?
>

That example is not just for Xcode, it works for Linux too. The
CMAKE_XCODE_ATTRIBUTE_... stuff is specific to Xcode, it provides a way to
set arbitrary project variables in the Xcode project file that CMake
generates. Other generators don't need/support such a mechanism.

In that article, the Xcode attributes are used to override the way the
compiler and linker are invoked. On Linux, CMake already supports the
RULE_LAUNCH_COMPILE and <LANG>_COMPILER_LAUNCHER properties for use with
Ninja or Makefiles to achieve this for you. It's not clear why you are
looking for a Linux equivalent of the Xcode attributes.

If you need to set CCACHE_DIR as an environment variable, then my previous
email shows how to embed that in the launcher script, which will work for
both Xcode and Linux (since the same launcher script is ultimately being
invoked for both cases). All that said, I've never needed to set CCACHE_DIR
and I mix OSX and iOS builds on the same machine. As has already been
mentioned by someone else, ccache is smart enough to recognise the two
builds as different because the command lines will be different, hence you
don't get an iOS object file for a OSX build, for example.





>
> On Jan 19, 2017, at 2:11 PM, Craig Scott <craig.scott at crascit.com> wrote:
>
> Ah, sorry, I misunderstood what CCACHE_DIR was for. Nevertheless, the
> method in that linked article could be easily modified to do what you want.
> Simply add the setting of the environment variable to the launch scripts.
> Since those launch scripts are copied across to the build dir at configure
> time and they support variable substitutions, you can even have the value
> of CCACHE_DIR be settable from CMake if you want. For example, your
> launch-c.in file could look like this:
>
> #!/bin/sh
> export CCACHE_CPP2=true
> export CCACHE_DIR=${CCACHE_DIR}
> exec "${RULE_LAUNCH_COMPILE}" "${CMAKE_C_COMPILER}" "$@"
> When you run CMake, it substitutes the value of each of the above
> variables as they are set when the configure_file() command is called.
> Therefore, the configure step bakes in the value of CCACHE_DIR and it won't
> need to be set in your environment when you do the build step. Note that
> the substitutions are substituting CMake variables, not environment
> variables, so if you wanted to pass through a CCACHE_DIR environment
> variable instead, you would do something like this:
>
> #!/bin/sh
> export CCACHE_CPP2=true
> export CCACHE_DIR=$*ENV*{CCACHE_DIR}
> exec "${RULE_LAUNCH_COMPILE}" "${CMAKE_C_COMPILER}" "$@"
> Probably better to do that in your CMakeLists.txt instead though and leave
> the launch-c.in script as in the first case above. This would mean your
> CMakeLists.txt would have a line like this somewhere:
>
> set(CCACHE_DIR $ENV{CCACHE_DIR}).
>
> Note, however, that relying on environment variables for configure or
> build steps is not so robust. If, for example, you change a CMakeLists.txt
> file or something else in your project requires CMake to be re-run, then
> CMake can re-run as part of a build. This then means the environment
> variables have to be the same between your CMake runs and your build runs.
> That's normally not a problem for most people, but thought I'd mention it
> just in case. Personally, I try to avoid relying on environment variables
> and instead have such values passed in as CMake cache variables like so:
>
> cmake -G Ninja -DCCACHE_DIR=${CCACHE_DIR} ../src
>
> This saves the value in the cache and then it is preserved regardless of
> what environment I have when I do subsequent build steps.
>
>
>
>
> On Fri, Jan 20, 2017 at 7:44 AM, David Lind <davidklind at gmail.com> wrote:
>
>> Scott,
>>
>> I have find_program implemented to find ccache, as shown below.
>>
>>     find_program(CCACHE ccache)
>>     if(CCACHE)
>>         set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE ${CCACHE})
>>         set_property(GLOBAL PROPERTY RULE_LAUNCH_LINK ${CCACHE})
>>     endif()
>>
>> That’s not the issue. The issue is telling ccache where to place it’s
>> cache files. If I compiles for toolchain X, Y and X, I need to set
>> CCACHE_DIR accordingly. Otherwise the cache will be useless.
>>
>> —Dave
>>
>> On Jan 19, 2017, at 12:57 PM, Craig Scott <craig.scott at crascit.com>
>> wrote:
>>
>> Rather than relying on environment variables, you can use CMake's
>> find_program() command to find ccache on your path and then tell CMake to
>> use that as a launcher. You can find an article with a detailed explanation
>> of how to set this up here:
>>
>> https://crascit.com/2016/04/09/using-ccache-with-cmake/
>>
>> An advantage of this approach is that the build will work with or without
>> ccache installed. We've been using this in production for some time now and
>> it works very smoothly. The technique can probably also be extended to
>> support Windows too with clcache <https://github.com/frerich/clcache>,
>> but I haven't tried that yet.
>>
>>
>> On Fri, Jan 20, 2017 at 5:00 AM, David Lind <davidklind at gmail.com> wrote:
>>
>>> I am porting existing makefiles to cmake. One of the key features of
>>> these makefiles is setting the CCACHE_DIR environment variable based upon
>>> the tool chain selected.
>>>
>>> I have TC_<toolchain>.cmake files created. Ideally, I would add a line
>>> to these files to set the CCACHE_DIR. But, CMake doesn’t have the ability
>>> to set environment variables during the build step. So, I’m stuck.
>>>
>>> Has anyone encountered this kind of situation?
>>>
>>> —Dave
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/cmake
>>
>>
>>
>>
>> --
>> Craig Scott
>> Melbourne, Australia
>> https://crascit.com
>>
>>
>>
>
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
>
>


-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170201/93d441e0/attachment.html>


More information about the CMake mailing list