|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0013209||CMake||CMake||public||2012-05-10 11:19||2012-10-01 13:22|
|Product Version||CMake 2.8.8|
|Target Version||Fixed in Version|
|Summary||0013209: automagical custom target generation to consolidate duplicate custom commands|
|Description||When 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 Reproduce||tar -xzf dummy.tar.gz|
|Additional Information||If this issue cannot be solved in cmake, it would be nice to add at an FAQ item for it.|
|Tags||No tags attached.|
|Attached Files||dummy.tar.gz [^] (943 bytes) 2012-05-10 11:19|
Brad King (manager)
FAQ added with explanation and solution:
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.
Brad King (manager)
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.
David Cole (manager)
|Closing resolved issues that have not been updated in more than 4 months.|
|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|