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,103
    • Issues 4,103
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 17
    • Merge requests 17
  • 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
  • #17524
Closed
Open
Issue created Nov 29, 2017 by Yurii Batrak@joewkrContributor

Ninja: re-compilation cascades in Fortran builds

When cmake uses the "Unix Makefiles" generator it produces a makefile that contains some additional "magic" to avoid unnecessary re-compilations. Basically, when a Fortran module is re-compiled, cmake checks, does the produced *.mod file differ from the *.mod file from previous compilation, and is able to figure out that modules are actually the same.

Contrary, when cmake uses the "Ninja" generator such optimization isn't applied and if Fortran compiler updates timestamps of module files on each re-compilation, even if the *.mod file itself wasn't changed (as in case of ifort), an incremental build with ninja falls in a series of unnecessary re-compilations.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking