[Scons-users] TempFileMunge conflicts with ccache
Mats Wichmann
mats at wichmann.us
Wed Dec 19 10:12:36 EST 2018
On 12/19/18 8:03 AM, Andrew C. Morrow wrote:
> While investigating this issue, I think I discovered a potentially more
> serious issue. Evaluation of a build where CC is set to a multi token value
> like ccache gcc will not rebuild files if the compiler is upgraded, because
> CommandAction.get_implicit_deps only considers the first token of the
> command line as an implicit dependency which must be checked for
> up-to-date-ness. In the case of CC="ccache gcc" build, that would result in
> a rebuild when the ccache binary changed, but not when the gcc binary
> changed.
>
> I'm not sure if there is anything really that can be done about that, but
> maybe some guard rails around setting tool variables to multi token values
> would be a good idea?
>
>
>
> On Thu, Dec 6, 2018 at 12:14 PM Andrew C. Morrow <andrew.c.morrow at gmail.com>
> wrote:
>
>>
>> In the MongoDB build, we enable TempFileMunge for non-windows platforms,
>> since sometimes we have truly astronomically long link lines which break
>> even the linux command line length limitations.
>>
>> https://github.com/mongodb/mongo/blob/master/SConstruct#L1478-L1496
>>
>> A user reported that their builds failed when trying to use ccache:
>> https://jira.mongodb.org/browse/SERVER-38389
>>
>> It appears that TempFileMunge just assumes that only the first token of
>> the command is actually the "compiler", and ends up feeding the response
>> file directly to ccache, rather than invoking, say `ccache
>> g++ @/path/to/temp/file`.
>>
>> On the other hand, could this even work in principle? Is ccache smart
>> enough to know to "see into" the response file in order to interact with
>> its cache correctly? This CMake bug suggests not:
>> https://github.com/kripken/emscripten/issues/4750
>>
>> I did steer the user towards using the SCons cache instead of ccache, and
>> provided a workaround of setting MAXLINELENGTH=<huge-number>
>>
>> At the very least, if ccache and response files can't be mixed, perhaps
>> TempFileMunge could include some guard rails here to bail out if it sees
>> the first token to be ccache.
>>
>> Thoughts?
Isn't the more normal usage model to let ccache masquerade as gcc, in
which case there's only one compiler token value on the line?
That is, from the manpage:
SYNOPSIS
...
ccache compiler [compiler options]
compiler [compiler options] (via symbolic link)
use the second form? that doesn't necessarily excuse scons not
understanding about the other scenario, but could provide a way forward.
More information about the Scons-users
mailing list