[CMake] Setting compile defs with: Cuda, add_subdirectory, and set_target_properties (COMPILE_DEFINITIONS)

Mon Aug 16 17:19:13 EDT 2010

On Mon, Aug 16, 2010 at 2:17 PM, Brian Davis <bitminer at gmail.com> wrote:

> James I was going to cc you on my latest findings.  Thanks for giving me a
> "way out" with out having to patch the FindCUDA.  I recently came to the
> same conclusion as your recent post.
>
>
I just noticed your email in my FindCUDA filter from the CMake list.  I'm
not sure why it didn't show up sooner.

> 1. CUDA_ATTACH_VS_BUILD_RULE_TO_
> CUDA_FILE can really only cause problems with parallel builds.  Are you
> performing parallel builds?
>
> No I am not
>
>
> 2. Have you tried to disable this flag?
>
> Yes I have and it turns out I must in order for me to get my .cu file to be
> compiled with correct -DDefines.
>
>
I don't believe this is true.  So what happens when you add the same file to
more than one project in the same directory is this (more or less).

project1
  -- myfile.cu: had rule to build project1_myfile.cu.obj from myfile.cu

project2
  CMake Rules
    -- cmake_build_..._myfile.rule: has rule to build project2_myfile.cu.obj
from myfile.cu
  -- myfile.cu: has rule to build project1_myfile.cu.obj from myfile.cu

The problem you have when building in parallel is there are two build
commands for project1_myfile.cu.obj.  If you compile project1 and project2
at the same time, you can get a race condition for project1_myfile.cu.obj.
If you build them one at a time, project2 will run the cmake....rule file
that compiles project2_myfile.cu.obj then try to compile myfile.cu's rule,
but see that it is done (from project1).  At any rate, I'm not sure if this
is ultimately related to your problem or the other issue you described were
at the root of the problem.

Incidentily, you can use the same file in different projects if they are in
different directories (i.e. CMake directory scopes) without causing this to
happen.

> I also did as you suggested above though I wish I would have looked at my
> email sooner as I ended up coming to the same conclusion.
>
> first it appears I must remove
> --snip--
>
>         foreach( DEFINE_STR ${ARG_DEFINES} )
>             message( "DEFINE_STR = ${DEFINE_STR}" )
>             add_definitions( -D${DEFINE_STR} )
>         endforeach()
> --end snip--
>
> and change as you stated:
>
> --snip--
>
>         CUDA_ADD_LIBRARY( ${LIB_NAME} SHARED ${MATLAB_CUDA_FILES} OPTIONS
> ${my_nvcc_flags} )
> --end snip
>
> to
>
> -snip--
>
> if(DEFINED ARG_CU_SOURCES )
>         message("\tARG_CU_SOURCES is defined as = ${ARG_CU_SOURCES}" )
>
>         CUDA_ADD_LIBRARY( ${LIB_NAME} SHARED ${MATLAB_CUDA_FILES}
>             OPTIONS
>                 DEBUG ${DEFINITIONS_STRING}
>                 RELEASE ${DEFINITIONS_STRING}
>                 MINSIZEREL ${DEFINITIONS_STRING}
>                 RELWITHDEBINFO ${DEFINITIONS_STRING}
>         )
>     else()
> --end snip--
>
>
Why are you specifying the same option for every type of build?  Any
arguments after OPTIONS and before DEBUG, RELEASE, etc. will be applied to
all build types.

> as
>
> --snip from FindCuda.cmake--
> macro(CUDA_PARSE_NVCC_OPTIONS _option_prefix)
>   set( _found_config )
>   foreach(arg ${ARGN})
>     # Determine if we are dealing with a perconfiguration flag
>     foreach(config ${CUDA_configuration_types})
>       string(TOUPPER ${config} config_upper)
>       if (arg STREQUAL "${config_upper}")
>         set( _found_config _${arg})
> message( "_found_config = ${_found_config}" )
>         # Set arg to nothing to keep it from being processed further
>         set( arg )
>       endif()
>     endforeach()
>
>     if ( arg )
>       list(APPEND ${_option_prefix}${_found_config} "${arg}")
>     endif()
>   endforeach()
> endmacro()
> --end snip--
>
> searches for DEBUG, RELEASE, ... etc to append to
>
> which give me the MSVS output I am looking for.
>
> --snip--
> 2>C:/CUDA/bin64/nvcc.exe
> C:/Users/bdavis5/Documents/QS/QS-NIH/source/branches/trunk/source/Matlab/lib/3rdParty/Siemens/gpu/PMatrixRecon/gpuPMatrixRecon.cu
> -arch sm_13 --ptxas-options=-v -maxrregcount=32 -Xcompiler
> /EHsc,/W3,/nologo,/Od,/Zi,/MTd -DCUDADeviceProperties_DLLExport=yes
> -DCPU_RECON=yes -m64 -DcpuPMatrixRecon_EXPORTS -ccbin "c:/Program Files
> (x86)/Microsoft Visual Studio 9.0/VC/bin" -DNVCC -M -o
> C:/Users/bdavis5/Documents/QS/QS-NIH/source/branches/trunk/build/dvip4-Win64/source/Matlab/lib/3rdParty/Siemens/gpu/PMatrixRecon/CMakeFiles/cpuPMatrixRecon_generated_gpuPMatrixRecon.cu.obj.NVCC-depend
> -IC:/CUDA/include
> -IC:/Users/bdavis5/Documents/QS/QS-NIH/source/branches/trunk/source/cpp/lib/3rdParty/Win/boost-cmake-1_41_0
> "-IC:/ProgramData/NVIDIA Corporation/NVIDIA GPU Computing SDK/C/common/inc"
> -IC:/Users/bdavis5/Documents/QS/QS-NIH/source/branches/trunk/build/Windows-6.0/install/include/vtk-5.6
> -IC:/Users/bdavis5/Documents/QS/QS-NIH/source/branches/trunk/build/Windows-6.0/install/include/VTKEdge
> "-IC:/Program Files/MATLAB/R2010a/extern/include"
> -IC:/Users/bdavis5/Documents/QS/QS-NIH/source/branches/trunk/source/Matlab/lib/3rdParty/Siemens/gpu/PMatrixRecon/.
> -IC:/CUDA/include
> 2>gpuPMatrixRecon.cu
> --end snip--
>
> Note no more -DGPU_RECON ... Yippie!!!
>
> in response to:
>
> --snip--
>
> FindCUDA.cmake can't use the target properties, because target properties
> can be set anytime, and the FindCUDA.cmake script needs the properties at
> the time cuda_add_libraries is called.  This is because FindCUDA.cmake
> generates build scripts at configure time and not at generate time.
> --end snip--
>
> Yes I noticed this when looking, debugging, testing FindCuda.  It is the
> infamous chicken-in-egg problem.  get_target_properties can't be used in the
> FindCuda.cmake script (I tried modifying it)  as I cannot call
> set_target_properties before calling CUDA_ADD_LIBRARY as the target does not
> exist until after this call.
>
>
I really wish there was a generate time hook I could use, but alas there
isn't.  This is as good as it's going to get with how CMake is currently
implemented.

>
> I appreciate the help and hope this helps someone else
>

Again, sorry I didn't notice your email sooner.  I believe my email address
(at least my NVIDIA one) is in the documentation.

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100816/305e1f90/attachment-0001.htm>