MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0012945CMakeCMakepublic2012-02-08 06:402012-09-03 16:00
ReporterAlessio 
Assigned ToBrad King 
PriorityhighSeverityfeatureReproducibilityalways
StatusclosedResolutionduplicate 
PlatformOSOS Version
Product VersionCMake 2.8.7 
Target VersionFixed in Version 
Summary0012945: CMake should support custom commands that can vary by configuration
DescriptionI think I have a use-case for the feature requested in issue 9974.

Boost DLLs/SOs need to be copied in place to run tests. The have config-specific filenames, so the only way I can see to make it work is to copy all of them for all configs, which is not ideal. Boost_SHARED_LIBRARIES_RELEASE and Boost_SHARED_LIBRARIES_DEBUG below are constructed from the variables provided by the FindBoost module.

foreach(file ${Boost_SHARED_LIBRARIES_RELEASE} ${Boost_SHARED_LIBRARIES_DEBUG})
    mb_message(STATUS "copying ${file} to binary dir")
    add_custom_command(
        TARGET SETUP_TESTS PRE_BUILD
        COMMAND ${CMAKE_COMMAND} -E copy_if_different ${file} $<TARGET_FILE_DIR:${mod_name}>)
endforeach()
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
duplicate of 0009974closed Brad King CMake should support custom commands that can vary by configuration. 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2012-02-08 06:40AlessioNew Issue
2012-02-08 09:00Brad KingRelationship addedrelated to 0009974
2012-02-10 02:16James BiglerNote Added: 0028551
2012-03-09 14:52Brad KingNote Added: 0028886
2012-03-09 14:52Brad KingRelationship replacedduplicate of 0009974
2012-03-09 14:52Brad KingStatusnew => resolved
2012-03-09 14:52Brad KingResolutionopen => duplicate
2012-03-09 14:52Brad KingAssigned To => Brad King
2012-09-03 16:00David ColeNote Added: 0030834
2012-09-03 16:00David ColeStatusresolved => closed

Notes
(0028551)
James Bigler   
2012-02-10 02:16   
Not that I'm suggesting CMake doesn't need this, but I've worked around this particular issue with my FindCUDA.cmake module by having a CMake script that is run by the build. The CMake script takes as one of its arguments the current configuration, and then the script decides how to interpret that.

in FindCUDA.cmake:

  if(CMAKE_GENERATOR MATCHES "Visual Studio")
    set( CUDA_build_configuration "$(ConfigurationName)" )
  else()
    set( CUDA_build_configuration "${CMAKE_BUILD_TYPE}")
  endif()

      add_custom_command(
        OUTPUT ${generated_file}
        COMMAND ${CMAKE_COMMAND} ARGS
          -D build_configuration:STRING=${CUDA_build_configuration}
        ...

And then in the script (FindCUDA/run_nvcc.cmake):

if(NOT build_configuration)
  set(build_configuration Debug)
endif()
string(TOUPPER "${build_configuration}" build_configuration)

I can then use the build_configuration variable to look for configuration dependent information:

foreach(flag ${CMAKE_HOST_FLAGS} ${CMAKE_HOST_FLAGS_${build_configuration}})
  # Extra quotes are added around each flag to help nvcc parse out flags with spaces.
  set(nvcc_host_compiler_flags "${nvcc_host_compiler_flags},\"${flag}\"")
endforeach()
(0028886)
Brad King   
2012-03-09 14:52   
Resolving as duplicate of 0009974 now that it has been reopened.

Re 0012945:0028551: You can use the $<CONFIGURATION> generator expression in the custom command arguments to pass the configuration to the script independent of the generator.
(0030834)
David Cole   
2012-09-03 16:00   
Closing resolved issues that have not been updated in more than 4 months.