DISABLE_ABI_CHECK could probably be dropped and still have cache friendliness

[stellaraccident]

I recently spent a little time scratching my head on why ccache seems ineffective with XRT. I noted that the hashes were changing run to run. I haven't tracked through it but it seems the utility option to enable ccache has the by-product of compiling with DISABLE_ABI_CHECK. I wonder if it is possible to have it both ways. The cache unfriendliness is coming from version.h being included. This is a generated file that has (it looks like) run to run variation.

In other projects, I've typically seen this factored so that such variation is hidden in a cpp file and only the variables are exported. Without a root header changing on each run, it makes it more cache friendly. You can still have an option to disable stamping to save this one file recompile/relink, but that is usually a small cost compared to invalidating the whole project.

[stsoe]

Agreed. It is problem when version.h is included, but this is the file that is used to guarantee ABI compatibility in functions produce output with different format between releases of XRT. You can disable the version check by setting DISABLE_ABI_CHECK, which is a trick we employ on our private ccache functionality for exactly the reason you state. This has to be a compile time check as opposed to a runtime check. Binaries in the field have compiled the version into the APIs they are using, so only new binaries get ABI updates.

But you have the effects of DISABLE_ABI_CHECK reversed, because only when defining this variable do you reduce the impact of version.h changing from cmake to cmake invocation. You can also do purely incremental XRT builds by using 'build.sh -nocmake' which prevents CMake generation unless of course any CMakeLists.txt have changed.