CMake Zero Check fails to detect updates in CMakeLists.txt files for Xcode generator

Question

Background

I have big project which builds runs on windows perfectly. When some changes are applied in CMakeLists.txt and project is build, Visual Studio project is properly updated.

Xcode version: 10.0 (10A255) or 10.1 (10B61) (tested on different machines).

CMake version: 3.12.2 or 3.13.1

Problem

Problem appears when same project is build on Mac OS for Xcode. After configuring CMake:

cmake .. -G Xcode

Generated project works fine, everything builds properly and test are passing.

Now when CMakeLists.txt files are modified (when developing project or when fetching new changes from repository) and ZERO_CHECK or BUILD_ALL are selected, build doesn't lead to Xcode project update. Invoking cmake . doesn't detect changes too.

Workaround

The best workaround I've found is deletingeverythingtwo files: cmake_install.cmake and CMakeCache.txt . Then rerun command which generates project cmake .. -G Xcode .
In this scenario whole detection is redone from scratch, but at least build doesn't start from zero (unchanged files are not recompiled).

This is painful, since lots of manual stuff must be done, and project have to be recreated and this consumes time.

Hints

In some previous project I had similar problem, but it was happening only if maven was detecting updates for dependencies, so it happened quite rarely. When it happened I just called touch CMakeLists.txt and build again and this workaround was fine. This solution doesn't applies since every build has this issue.

I was suspecting that protobuf generation procedure has something with it, but when I've disabled it problem still persists.

I've tried to provide complete minimal example, by creating simple project file, but I was not able to reproduce the issue. For all other projects it just works, so system configuration is not the issue.

Questions

How can I debug project generation process when running cmake to find source of this problem?

Is this a known problem?

Is there a better workaround which will not leadto full rebuildregenerating project file (which also involves detecting system capabilities)?

Answer 1

Is this a known problem?

Over on the CMake Discourse, Craig Scott (one of the CMake maintainers) has commented on a variant of this bug as a known architectural limitation of Xcode:

With the Xcode generator, targets have a dependency on the ZERO_CHECK target, which is what re-runs cmake for you automatically if something changed. But the problem is that the rest of the build in that run still uses the old details from before cmake . gets run. If you build again, that rebuilds anything whose details changed, but explicitly re-running cmake . first if you know something about the project changed will be more robust and probably avoid more unnecessary rebuilds.

-- https://discourse.cmake.org/t/documented-criteria-for-build-correctness/3087/2?u=alex

Your comment that "invoking cmake . doesn't detect changes" is strange in light of this, but it could be that old CMake versions, like 3.12 and 3.13 which you were using when this question was asked, had a bug that has since been fixed. It could also be something project-specific that we can only guess at. Missing a CMAKE_CONFIGURE_DEPENDS directory property? Have a bad set(... CACHE ... FORCE) call? Can't say...