View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0013209CMakeCMakepublic2012-05-10 11:192012-10-01 13:22
Reporterwbu 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionsuspended 
PlatformGNU/LinuxOSSuseOS Version11.4
Product VersionCMake 2.8.8 
Target VersionFixed in Version 
Summary0013209: automagical custom target generation to consolidate duplicate custom commands
DescriptionWhen building a dynamic and static library from the same source and a custom command is involved, the custom command will be called twice at the same time with the same output, most likely leading to undefined behavior.

I really tried hard to get the custom command called with different output paths, like what is done with the object files when compiling. But i could not find a way to achieve this.

My current workaround is to add a dependency for the dynamic library to the static library, which is not really what i want.

Attached is a stripped down dummy project, that most likely fails to compile, because the C-code is doubled by calling the modify.sh in two processes at the same time.

tested with cmake 2.8.3 and 2.8.8
Steps To Reproducetar -xzf dummy.tar.gz
cd dummy
make
Additional InformationIf this issue cannot be solved in cmake, it would be nice to add at an FAQ item for it.
TagsNo tags attached.
Attached Filesgz file icon dummy.tar.gz [^] (943 bytes) 2012-05-10 11:19

 Relationships

  Notes
(0029463)
Brad King (manager)
2012-05-10 11:42

 FAQ added with explanation and solution:

http://www.cmake.org/Wiki/CMake_FAQ#How_can_I_generate_a_file_used_in_more_than_one_target_in_the_same_directory.3F [^]
(0029464)
wbu (reporter)
2012-05-10 11:54

 Is it really impossible to fix this issue? The second workaround looks like it could be done automatically by cmake.

It's really hard to catch such issues, because they happen by chance.
(0029465)
Brad King (manager)
2012-05-10 12:05

 Custom commands *have* to be attached to targets because build systems like the VS IDE have no other place to put build rules at all.

Re 0013209:0029464: It might be possible to automatically identify groups of custom commands that are needed by multiple targets but it would require non-trivial analysis of all custom commands and all targets in a given directory. Then we would need a well-defined and unsurprising way to generate extra targets spontaneously to contain the commands. Furthermore it would have to be done in a backwards-compatible way so that build rules for existing projects do not change.

Marking as "suspended" until a volunteer comes to the developers list with a proposed design and time to implement it.
(0031125)
David Cole (manager)
2012-10-01 13:22

 Closing resolved issues that have not been updated in more than 4 months.

 Issue History
Date Modified Username Field Change
2012-05-10 11:19 wbu New Issue
2012-05-10 11:19 wbu File Added: dummy.tar.gz
2012-05-10 11:42 Brad King Note Added: 0029463
2012-05-10 11:42 Brad King Assigned To => Brad King
2012-05-10 11:42 Brad King Status new => resolved
2012-05-10 11:42 Brad King Resolution open => not fixable
2012-05-10 11:54 wbu Note Added: 0029464
2012-05-10 11:54 wbu Status resolved => feedback
2012-05-10 11:54 wbu Resolution not fixable => reopened
2012-05-10 12:05 Brad King Note Added: 0029465
2012-05-10 12:05 Brad King Assigned To Brad King =>
2012-05-10 12:05 Brad King Severity minor => feature
2012-05-10 12:05 Brad King Status feedback => resolved
2012-05-10 12:05 Brad King Resolution reopened => suspended
2012-05-10 12:05 Brad King Summary race condition with parallel build and custom command => automagical custom target generation to consolidate duplicate custom commands
2012-10-01 13:22 David Cole Note Added: 0031125
2012-10-01 13:22 David Cole Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team