C++ build setup to ignore changes in comments

Question

Is it possible to setup the build chain in a way such that any changes in comments (or whitespace) are ignored? For example whenever a comment in a header file is changed, every source file that includes it is re-compiled, even when that's completely unnecessary.

When the preprocessor is done with removing comments from the modified file, the build chain could first check if the output actually changed. If not, it should act as if the file itself didn't change.

I'm using Visual Studio 2010 btw.

Edit: @MikeSeymour, VS's cl.exe has a switch /Gm for minimal rebuilds. It's not well documented, but I think it kinda does what I'm asking for. But it's incompatible with the /MP switch for using multiple cores. On my dual core (w/ hyperthreading), /Gm would need to skip the compilation of ~3 out of 4 units on average. While I find it doubtful that this is the case, I'm not even sure how to evaluate whether /Gm is worth it or not.

Answer 1

Yes. You have to have a build system that will let you trigger build events if some predicate is true. What you'd like is a predicate that says, "this file has changed in an semantically interesting way".

A good approximation of such a predicate exists, in the form of our SmartDifferencers family of tools that compare source code files, using deep knowledge (e.g, a production parser) of the structure of the source code. In particular, the SmartDifferencer will show changes in source code in terms of changes to language constructs (e.g., identifiers, statements, declarations, blocks) and plausible editing actions (insert, replace, delete, move, rename, rename-across block, etc.). It isn't interested in layout or comments (unless you force it to be). So it is pretty easy to get the SmartDifferencer to tell if a source code file has changed something other than comments or whitespace. SmartDifferencers exist for a wide variety of languages.

Now, how do you get the build system to cooperate? Unix Make triggers on a predicate, but not this kind; what it actually does is trigger build events on entities based on recency of file dates compared to the target. You can fake this by having a dependency on a "changed_signal" file, by manufacturing such a file, if the SmartDifferencer sees an interesting difference.