Re: TempFileMunge conflicts with ccache
"Andrew C. Morrow" <[email protected]>
| Newsgroups | gmane.comp.programming.tools.scons.user |
|---|---|
| Message-ID | <CA+Acj4fvedt+kW+ug5Ea379GVQwRbdWNLC+pKqbDJN72YOErLQ@mail.gmail.com> |
In this case, I'm sort of just relaying word from someone who was trying to build MongoDB this way. I don't use ccache, I use the SCons cache. But I thought the assumption baked into Action was worth flagging. On Wed, Dec 19, 2018 at 10:12 AM Mats Wichmann <[email protected]> wrote: > 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