Thanks for the PR!

TBH though I don't really have any idea what's going on. Is this a bug in cmake? Are other consumers of cmake expected to handle things like this?

@alexcrichton

Is this a bug in cmake?
Are other consumers of cmake expected to handle things like this?

As I know it is from 'Have no time' to 'Won't fix' issue in cmake:
https://cmake.org/Bug/view.php?id=14841
https://cmake.org/Bug/view.php?id=14294

And proper way to handle this is

If you want to use other then default compiler you should use another build directory

And for my C++ mixed with Rust project I used this solution, in CI that test build with clang/gcc on Linux I just set separate CARGO_TARGET_DIR for clang case.
This is huge waste of CPU and disk resources, because of there are ~100 crates cached in target directory and only two use cmake-rs, but this is server, who cares.

But the same thing on my macbook with actually the same compiler is killing me,
so I decided to add the proper way to handle this issue.

cmake's gitlab had was turn off for maintenance, so more relevant link to current cmake's issue tracker:

https://gitlab.kitware.com/cmake/cmake/-/issues/18959

The most interesting parts are:

Brad King Owner
We generally do not support changing the compiler in an existing build tree. Please create a separate build tree for each compiler.
There is partial/unofficial support for changing the compiler for historical reasons, and is retained for compatibility.
That message telling you exactly that it is deleting all the cache entries, which includes CMAKE_CXX_FLAGS

Craig Scott Maintainer
A very common corner case for this is where the path to the compiler changes, but it ends up effectively being the same compiler anyway.
...
That's a long way of saying that I think it needs to be okay to change the compiler path as long as the compiler ID, version, etc. don't change. The user pain that would arise if we don't could be high.

The second quote is exactly my case. The problem is that cmake just return 0 in that case,
and you can see it's message about resetting the cache until you run cargo with -vv options.
And for example I find out that the sqlite3 was build without r-tree support while build.rs provide this option only when I run application.

After several day of testing I am still get unreliable results sometimes. Much less often, but still.
Looks like better make more reliable change - for each set of CMAKE_CC|CXX_COMPILER create separate directory.

I am going to redo this PR.