Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • CMake CMake
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 4,107
    • Issues 4,107
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 19
    • Merge requests 19
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • External wiki
    • External wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • CMakeCMake
  • CMakeCMake
  • Issues
  • #21698
Closed
Open
Issue created Jan 13, 2021 by Borislav Stanimirov@iboB

Improve FetchContent performance

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.

Edited Jan 13, 2021 by Borislav Stanimirov
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking