|
Notes |
|
|
(0018643)
|
|
Johannes Brunen
|
|
2009-12-02 10:11
|
|
Hello,
this is a feature which I also desperately miss.
Best,
Johannes |
|
|
|
(0024183)
|
|
Brad King
|
|
2010-12-15 14:12
|
|
I converted the patch to a commit based on 8e7a630f (KWSys Nightly Date Stamp, 2009-11-26):
0001-Per-config-add_custom_command.patch |
|
|
|
(0024185)
|
|
Brad King
|
|
2010-12-15 14:26
|
|
Rebased on commit a14a8562 from master:
a14a8562+0001-Per-config-add_custom_command.patch |
|
|
|
(0024186)
|
|
Brad King
|
|
2010-12-15 14:35
|
|
Unfortunately I didn't know about this patch until today. During the last week I've been working on some custom command implementation refactoring which conflicts with this patch.
I'm working on a feature I've wanted to do for a long time that has also been requested in issue 0011209. It will allow code like this:
add_executable(myexe ...)
add_custom_command(OUTPUT ...
COMMAND echo $<TARGET_FILE:myexe> $<CONFIGURATION>
...)
The $<> syntax is a "generator expression" that gets replaced on a per-config basis. See CMake 2.8's add_test documentation for all current generator expressions. I'm basically adding support to add_custom_command for them.
This kind of feature removes IMO most of the need for per-config custom commands. However, I'm not against integrating the patch from this issue and resolving the conflicts. Do you have an example use case that is not covered by generator expressions? Also, please propose a new test under Tests/ to cover the proposed feature. |
|
|
|
(0027126)
|
|
Brad King
|
|
2011-07-29 18:07
|
|
The generator expression support described in 0011209 has been released.
I'm resolving this as "suspended" pending proposed use cases not handled by generator expressions as requested in 0009974:0024186. Furthermore, the patch will have to be rebased on master. |
|
|
|
(0028115)
|
|
David Cole
|
|
2012-01-02 15:56
|
|
|
Closing resolved issues that have not been updated in more than 4 months. |
|
|
|
(0028884)
|
|
Brad King
|
|
2012-03-09 14:44
|
|
|
Re-opening as the central issue for discussion of this feature (since it is the only one with a proposed patch). |
|
|
|
(0028969)
|
|
Mike Krus
|
2012-03-26 04:02
(edited on: 2012-03-26 04:04) |
|
+1 for this feature. The $<> "generator expressions" only apply to parameters of the command, so you cannot for example have per configuration output files. Adding a CONFIG command would let you do that
Alternative would be to have per-config depend rules for add_dependencies() but that is not currently possible I believe
|
|
|
|
(0028995)
|
|
Bjoern Thiel
|
|
2012-03-29 08:18
|
|
|
I'd really like to see this feature as it can help you to bring 3'rd party dlls into the build directory using VS e.g. for debugging or running tests. |
|
|
|
(0028996)
|
|
David Cole
|
|
2012-03-29 10:35
|
|
|
|
|
(0029032)
|
|
Bjoern Thiel
|
|
2012-04-02 03:40
|
|
|
Right. And in combination with ${CMAKE_BUILD_TYPE} one can work with nmake in parallel as well. But for differing names (zlib1.dll and zlibd1.dll) unfortunately I got stuck. |
|
|
|
(0029033)
|
|
Brad King
|
|
2012-04-02 09:28
|
|
A commonly proposed use case for this feature is to copy a per-config .dll dependency into an executable's directory using a post-build command. Here is how to do that with generator expressions:
add_library(z SHARED IMPORTED)
set_target_properties(z PROPERTIES
IMPORTED_CONFIGURATIONS "Release;Debug"
IMPORTED_LOCATION_RELEASE "c:/path/to/zlib1.dll"
IMPORTED_LOCATION_DEBUG "c:/path/to/zlib1d.dll"
IMPORTED_IMPLIB_RELEASE "c:/path/to/zlib.lib"
IMPORTED_IMPLIB_DEBUG "c:/path/to/zlibd.lib"
)
add_executable(foo foo.c)
target_link_libraries(foo z)
add_custom_command(TARGET foo POST_BUILD COMMAND
${CMAKE_COMMAND} -E copy $<TARGET_FILE:z> $<TARGET_FILE_DIR:foo>/$<TARGET_FILE_NAME:z>
)
|
|
|
|
(0029063)
|
|
chrislu
|
|
2012-04-03 05:08
|
|
here is my very ugly solution using "if EXIST" to distinguish the debug and release dll version. i really wish for this feature to solve such ugly solutions:
macro(scm_link_libraries)
set(in_platform ${ARGV0})
set(in_libraries ${ARGV})
list(REMOVE_AT in_libraries 0)
# first to the actual target_link_libraries
if (in_platform MATCHES ALL)
target_link_libraries(${PROJECT_NAME} ${in_libraries})
else (in_platform MATCHES ALL)
if (${in_platform})
target_link_libraries(${PROJECT_NAME} ${in_libraries})
endif (${in_platform})
endif (in_platform MATCHES ALL)
get_target_property(target_type ${PROJECT_NAME} TYPE)
if (target_type MATCHES EXECUTABLE)
if (in_platform MATCHES ALL OR in_platform MATCHES WIN32)
get_directory_property(link_dirs LINK_DIRECTORIES)
list(REMOVE_ITEM in_libraries debug optimized general)
list(REMOVE_ITEM link_dirs ${SCHISM_LIBRARY_DIR})
set(conf_list release debug)
foreach(conf ${conf_list})
foreach(link_lib ${in_libraries})
set(link_lib_dll ${link_lib}.dll)
foreach(ldir ${link_dirs})
set(dll_path ${ldir}/${conf}/${link_lib_dll})
if (EXISTS ${dll_path})
# make if fail for the wrong configuration
string(REPLACE /${conf}/ "/$<CONFIGURATION>/" dll_path ${dll_path})
add_custom_command(TARGET ${PROJECT_NAME} POST_BUILD
COMMAND if EXIST ${dll_path} ${CMAKE_COMMAND} -E echo "copying ${link_lib_dll} to ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$<CONFIGURATION>/"
COMMAND if EXIST ${dll_path} ${CMAKE_COMMAND} -E copy_if_different ${dll_path} ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$<CONFIGURATION>/)
endif (EXISTS ${dll_path})
endforeach(ldir)
endforeach(link_lib)
endforeach(conf)
endif (in_platform MATCHES ALL OR in_platform MATCHES WIN32)
endif (target_type MATCHES EXECUTABLE)
endmacro(scm_link_libraries)
macro(scm_copy_shared_libraries)
set(in_platform ${ARGV0})
set(in_libraries ${ARGV})
list(REMOVE_AT in_libraries 0)
if (${in_platform} OR in_platform MATCHES ALL)
foreach(shlib ${in_libraries})
#message(${shlib})
#message(${in_platform})
#file(GLOB_RECURSE scm_glob_dlls ${GLOBAL_EXT_DIR}/lib/$<CONFIGURATION>/ ${shlib})
#message(${scm_glob_dlls})
set(scm_copy_dlls ${GLOBAL_EXT_DIR}/lib/$<CONFIGURATION>/${shlib})
set(scm_copy_path ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$<CONFIGURATION>/)
string(REPLACE "/" "\\" scm_copy_dlls ${scm_copy_dlls})
string(REPLACE "/" "\\" scm_copy_path ${scm_copy_path})
add_custom_command(TARGET ${PROJECT_NAME} POST_BUILD
COMMAND if EXIST ${scm_copy_dlls} ${CMAKE_COMMAND} -E echo "copying ${shlib} to ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$<CONFIGURATION>/"
COMMAND if EXIST ${scm_copy_dlls} ${CMAKE_COMMAND} -E copy_if_different ${scm_copy_dlls} ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$<CONFIGURATION>/)
endforeach(shlib)
# set(scm_copy_dlls ${SCHISM_LIBRARY_DIR}/$<CONFIGURATION>/*.dll)
# set(scm_copy_path ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$<CONFIGURATION>/)
# string(REPLACE "/" "\\" scm_copy_dlls ${scm_copy_dlls})
# string(REPLACE "/" "\\" scm_copy_path ${scm_copy_path})
#
# add_custom_command(TARGET ${PROJECT_NAME} POST_BUILD
# COMMAND if EXIST ${dll_path} ${CMAKE_COMMAND} -E echo "copying ${link_lib_dll} to ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$<CONFIGURATION>/"
# COMMAND if EXIST ${dll_path} ${CMAKE_COMMAND} -E copy_if_different ${dll_path} ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$<CONFIGURATION>/)
endif (${in_platform} OR in_platform MATCHES ALL)
endmacro(scm_copy_shared_libraries) |
|
|
|
(0029926)
|
|
chrislu
|
|
2012-07-06 06:51
|
|
|
is there any update on this issue? will this be implemented into cmake in future revisions? |
|
|
|
(0029929)
|
|
David Cole
|
|
2012-07-06 10:21
|
|
No updates beyond the notes already posted here.
We already have per-configuration add_test calls. Eventually, we will probably also have per-configuration add_custom_command calls. But to the best of my knowledge nobody is actively working on it, or has a specific timing in mind. |
|
|
|
(0032139)
|
|
void.pointer
|
|
2013-01-23 13:48
|
|
A few months back I offered to take this up but I've been so busy with work and other things I don't think I'll ever be able to work on this. Hoping someone can pick this up and add in the patch file already provided.
The workaround I use for this right now involves creating 1 custom target per configuration, but all of them run in every configuration. For example:
copy_dlls_debug
copy_dlls_relwithdebinfo
copy_dlls_release
copy_dlls_minsizerel
When I build "Debug" in visual studio, all 4 will execute. Any chance of getting this worked on soon? |
|
|
|
(0032144)
|
|
Petr Kmoch
|
|
2013-01-24 04:41
|
|
Re: void.pointer's note, using such per-configuration custom targets can be combined with 0013587 (which is already marged to master) to turn off those targets for the unwanted configurations.
|
|
|
|
(0034772)
|
|
Bill MacDonald
|
|
2013-12-13 16:33
|
|
Can I ask for this to be considered again. We have a large project with many targets, each of which needs post processing tools chained to the linking (i.e not run every time but run only when the linker runs), and applied only to the release builds. (context: our software has security requirements and we must apply anti-debug tools to the release binaries. Obviously, you don't want anti-debug measures in your debug builds).
I might be able to use the above workaround, but given the number of targets and variants we are producing, it's going to make for a very heavy, very unwieldy solution file in VS and XCode. |
|
|
|
(0034810)
|
|
Brad King
|
|
2013-12-18 16:18
|
|
Re 0009974:0034772: The patch proposed here is now 3 years old and would need to be rebased and updated before it could be considered again.
In your use case you may be able to use a generator expression like $<CONFIGURATION> or $<CONFIG:Debug> to pass a parameter to your postprocessing tool (or a wrapper) to tell it whether to actually do anything. |
|
|
|
(0034986)
|
|
coordz
|
|
2014-01-22 08:44
|
|
|
I'm trying to use the workaround proposed by Brad and use generators. Sadly, this gets me close but not all the way. It has also got very complex and unclear. Please, please take this bug off the backlog, dust off the patch and slip it in ASAP. |
|
|
|
(0036739)
|
|
Yelmond
|
|
2014-09-07 17:01
|
|
Seconded! My main use case is that I have a per-build command for a specific configuration (Release) and I have NO commands for all other configurations. It would be nice to avoid adding any command for the other configurations - something the generator expressions solution doesn't support.
My current workaround is something like this:
add_custom_command(
TARGET target
PRE_BUILD
COMMAND if 1==$<CONFIG:Rlease> command arg1 arg2
COMMENT "Running pre-build event." )
But the suggested CONFIG parameter to add_custom_command() would be a lot more elegant. |
|
|
|
(0037490)
|
|
Davy Durham
|
|
2014-12-18 15:38
|
|
|
I also second this feature: I'd like to compress the final binary, but only in some release configurations. I can probably get away with passing the configuration to the script, but that makes less sense (IMO) than having a conditional as part of cmake's feature since the script now has to be aware of build configuration issues. |
|
|
|
(0041628)
|
|
Kitware Robot
|
|
2016-06-10 14:27
|
|
Resolving issue as `moved`.
This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page. |
|
CustomCommandsByConfiguration.zip (11,670) 2009-11-27 19:19
0001-Per-config-add_custom_command.patch (39,624) 2010-12-15 14:19