Re: TempFileMunge conflicts with ccache
Mats Wichmann <[email protected]>
| Newsgroups | gmane.comp.programming.tools.scons.user |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> > 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. _______________________________________________ Scons-users mailing list [email protected] https://pairlist4.pair.net/mailman/listinfo/scons-users