dblaikie added a comment. In https://reviews.llvm.org/D38061#1275845, @twoh wrote:
> @dblaikie I see. The problem we're experiencing is that with Clang's naming > scheme we end up having different function name between the original source > and the preprocessed source (as macro expansion changes the column number). I imagine that's not achievable, though - as soon as you have a multi-line macro at least, it seems like it'd be difficult to preserve (I guess you could put loc directives between every line in the macro to ensure every line was attributed to the line the macro was written on, maybe?) > This doesn't work well for me if I want to use distcc on top of our caching > system, as the caching scheme expects the output to be same as far as the > original source has not been changed (regardless of it's compiled directly or > first preprocessed then compiled), but the distcc preprocesses the source > locally then sends it to the remote build machine (and we do not turn distcc > on for all workflow). I wonder if you have any suggestion to resolve this > issue? Thanks! Best thing to do, I think, if possible, is teach the distributed build system not to fully preprocess but to use something like Clang's -frewrite-includes - this handles includes, but leaves macro definitions and uses in-place. This would preserve Clang's warning semantics (where macros can help inform Clang's diagnostic choices, improving diagnostic quality (lowering false positives, etc)) and other things like debug info. Repository: rC Clang https://reviews.llvm.org/D38061 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
