MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008121CMakeCMakepublic2008-11-19 12:362008-12-17 07:47
Reportermwoehlke 
Assigned ToBrad King 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product VersionCMake-2-6 
Target VersionFixed in Version 
Summary0008121: Please add all/fast target
Description<target>/fast is useful for quick builds when dependencies are known to be unchanged. However, it can be hard to remember target names, or multiple targets may be affected, and install/fast may not be desired. Please add an all/fast target.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2008-11-19 12:36mwoehlkeNew Issue
2008-12-04 02:57Philip LowmanNote Added: 0014282
2008-12-15 10:41Bill HoffmanStatusnew => assigned
2008-12-15 10:41Bill HoffmanAssigned To => Brad King
2008-12-16 09:28Brad KingNote Added: 0014366
2008-12-17 02:02Philip LowmanNote Added: 0014378
2008-12-17 07:47Brad KingNote Added: 0014381
2008-12-17 07:47Brad KingStatusassigned => closed
2008-12-17 07:47Brad KingResolutionopen => won't fix

Notes
(0014282)
Philip Lowman   
2008-12-04 02:57   
+1 =)
(0014366)
Brad King   
2008-12-16 09:28   
What do you propose that all/fast should build? The whole point of a foo/fast target is to build target 'foo' without any of its target-level dependencies and without updating its file-level dependencies. An all/fast rule would have no associated target to build. It cannot just depend on the /fast rules of all the targets because that would ignore target ordering requirements.
(0014378)
Philip Lowman   
2008-12-17 02:02   
There could be a "CMakeFiles/tgt.dir/all/fast" rule for every target similar to "CMakeFiles/tgt.dir/all". Then it would be possible to maintain the target-level dependency chain whilst skipping the file-level dependencies and cmake_check_build_system.

I'm not sure if this would result in a performance improvement measurable enough to justify adding the rule, however.
(0014381)
Brad King   
2008-12-17 07:47   
I agree that the performance would not be much better. The main reason the /fast targets were added as because CMake 2.4 did a *global* check of file-level dependencies even if only one target was going to be built. The /fast targets provided a quick work-around to this. CMake 2.6 isolates the file-level dependency updates on a per-target basis so building a subset of the targets is much faster. This makes the /fast targets less useful.

In my experience the time it takes to do the file-level dependency check for an entire target is less than the time taken to compile one C++ file. I have not conducted explicit experiments for this though.

I don't think an all/fast target is worth the time or complexity. If someone provides a patch along with experiments showing a significant time improvement on a real project I'll be more interested.