Stable IFC generation

Question

Currently MSVC generates different IFC file whenever I change *.ixx.

It doesn't matter, do I touch the interface or implementation. Even if I add a whitespace in private fragment of the module, MSVC will generate different IFC file which trigger recompilation of all dependencies.

Are there any plans to improve this? I want to put my definitions and implementations into single *.ixx file, but I also want incremental builds to work if I didn't touch the interface.

I know, there is open-sourced IFC SDK. So, technically I can achieve by creating my own build system, which would perform semantic comparison of two ifc. But this is enormous amount of work. In the other hand, it looks like msvc and MSBuild already almost do what I want except of one last step.

I want to know what the current plans about making IFC generation stable (or provide semantic hashes of content or something).

Answer 1

Thank you for reaching out.

MSVC currently regenerates the IFC file whenever the source changes even if it’s just whitespace because the IFC is a binary representation of the module. This triggers downstream projects to rebuild since MSBuild checks timestamps, not semantics. There’s no built-in option in MSVC to ignore non-semantic changes or provide a semantic hash today.

you can try

• Keep the public interface separate from implementation. Put interface in the primary module interface and move implementation to other module units. This reduces IFC churn.
• Use deterministic build settings in MSBuild for other parts of the project (helps with reproducibility, not semantic stability).
• If you need full semantic stability, you’d have to build a custom step using the open-source IFC SDK to compare IFC files semantically—this is complex.
• Some developers experiment with hash-based incremental build tools, but nothing official from MSVC yet.

No simple built-in solution exists right now. Best workaround is separating interface and implementation or building a custom pipeline if you need perfect stability.

Please let us know if you require any further assistance, we’re happy to help.

If you found this information useful, kindly mark this as "Accept Answer".

Answer 2

I have solved my problem by replacing cl.exe with my wrapper:

https://github.com/alprog/cl-wrapper

It simply redirect all the commands to the original compiler but also do additional logic:

• it checks, are we going to overwrite an existing IFC file
• if so, compare semantic content of the original and the overwritten files (using ifc-printer from IFC SDK)
• if they are identical, restore original last_write_time

It effectively prevents recompilation of dependencies, if only implementation/formating part of the file was changed. Seems to work pretty well in my homebrew scenario.