[Scons-users] TempFileMunge conflicts with ccache

[Andrew C. Morrow]

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?
>
> Thanks,
> Andrew
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20181219/3f9c697d/attachment.html>