Project

General

Profile

Bug #6792

Attempting to install change to fcl files triggers cmake configuration

Added by Brian Rebel over 5 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Target version:
Start date:
08/13/2014
Due date:
% Done:

100%

Estimated time:
Spent time:
Scope:
Internal
Experiment:
NOvA
SSI Package:
cetbuildtools
Co-Assignees:
Duration:

Description

NOvA users have noticed that if they change only a .fcl file in a source package and then execute

make (install)

in the package directory in the build area, the cmake configuration step is configured, which for NOvA takes several minutes to complete. The expectation would be that changing a .fcl file would not require a reconfiguration.

Changing .h, .cxx, or .cc files and doing the same procedure does not trigger a reconfiguration.

History

#1 Updated by Lynn Garren over 5 years ago

  • Status changed from New to Rejected

Unfortunately, this is a feature. fcl files are copied to the build directory so that they are available for make test. Because this copy is controlled by cmake, and because substitutions are inherently necessary for this copy, cmake must rerun it's configure step whenever you change a fcl file. The good news is that if you make a change in your fcl file, the file is being copied and you aren't unknowingly using an older copy of the fcl file.

#2 Updated by Christopher Green over 5 years ago

  • Status changed from Rejected to Resolved
  • Assignee changed from Lynn Garren to Christopher Green
  • Target version set to 2.01.00
  • % Done changed from 0 to 100

To be released with cetbuildtools v4_00_02: all copies of files into different places in the tree, such as FHiCL files or GDML files, is now done in a way that will not trigger a re-run of CMake if a file is changed. If you glob in your CMakeLists.txt, of course, then adding or removing a file will require such a re-run.

In general, avoid doing configure(... COPYONLY) or equivalent, since this is what triggers the behavior. Anything you can defer to the make step using add_custom_command (and add_custom_target, if necessary) in your own CMake macros, etc, should improve the time to run CMake on your project.

#3 Updated by Christopher Green over 5 years ago

  • Target version changed from 2.01.00 to 1.11.00

#4 Updated by Christopher Green over 5 years ago

  • Status changed from Resolved to Closed


Also available in: Atom PDF