GitLab

My analysis of the situation may be wrong, and I'd be very happy if it is so and the performance can be improved without rewriting FetchContent

FetchContent is awesome and is a great substitute for simple package management. I think that it's one of the most important and promising features of CMake. Its performance, however, seems to be very poor.

FetchContent_MakeAvailable easily takes more than a second per item each time it executes. So, even minor changes to the CMake scripts can result in many seconds of configuration.

It seems the reason for that is that it's implemented through ExternalProject_Add by running its sub-builds at configure time. This means that, for example, for a git-repo content to confirm that the source dir is at the correct tag (which should be essentially a noop), CMake runs and entire custom build step at configure time. The build step itself does nothing eventually, but it triggers the entire toolchain involved with the build.

I understand that this is a clever "hack" of sorts to make use of the existing functionality of ExternalProject_Add, but fetching content is not building. The heavy build machinery shouldn't be involved in this.

I think reimplementing FetchContent to do just that - fetch content - would be a great improvement, and will make CMake capable of entirely replacing nix for C and C++ project. If anything, external projects should be implemented through this proposed rewritten FetchContent.