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

Brian Davis bitminer at gmail.com
Mon Aug 16 13:12:32 EDT 2010


>
> --snip--
>
> Ah you're on windows, make sure that you deselect the option to
> associate the build rule with cu files as this does the wrong thing
> when you're compiling the same file multiple times with different
> defines.
> --end snip--
>
> Can you give me more info on this?  I have looked in CMake variables using
> search in CMake GUI, and googled on the web snippets of your text, but I did
> not find anything.  I'll keep looking.
>

Ok so I got back to having to resolve this issue and I found the reference
you made to "associating the build rules" in the CMake Manual Cuda section
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#module:FindCUDA.  The
flag in question is CUDA_ATTACH_VS_BUILD_RULE_TO_CUDA_FILE which is
documented as follows

--snip--
  CUDA_ATTACH_VS_BUILD_RULE_TO_CUDA_FILE (Default ON)
  -- Set to ON if you want the custom build rule to be attached to the
source
     file in Visual Studio.  Turn OFF if you add the same cuda file to
multiple
     targets.


     This allows the user to build the target from the CUDA file; however,
bad
     things can happen if the CUDA source file is added to multiple targets.
     When performing parallel builds it is possible for the custom build
     command to be run more than once and in parallel causing cryptic build
     errors.  VS runs the rules for every source file in the target, and a
     source can have only one rule no matter how many projects it is added
to.
     When the rule is run from multiple targets race conditions can occur on
     the generated file.  Eventually everything will get built, but if the
user
     is unaware of this behavior, there may be confusion.  It would be nice
if
     this script could detect the reuse of source files across multiple
targets
     and turn the option off for the user, but no good solution could be
found.
--end snip--

The bits about parallel builds, cryptic build errors, and bad things
happening make me uneasy.

This does have an effect on my build, but not the one desired.   What I end
up with is now both GPU_RECON and CPU_RECON defined for each project not
simply the first, GPU_RECON, as before.

--snip--
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 -m64 -DgpuReconPlugin_EXPORTS=yes
-DGPU_RECON=yes -DCUDADeviceProperties_DLLExport=yes -DGPU_RECON=yes
-DCUDADeviceProperties_DLLExport=yes -DCPU_RECON=yes
-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
--end snip--

Note the
--snip--
-DgpuReconPlugin_EXPORTS=yes -DGPU_RECON=yes
-DCUDADeviceProperties_DLLExport=yes -DGPU_RECON=yes
-DCUDADeviceProperties_DLLExport=yes -DCPU_RECON=yes -DcpuPMatrixRecon
--end snip

It appears as though CMake keeps tacking on the the compile flags for CU and
other targets of which there are three targets in this directory.  Maybe I
need multiple directories for each target ugh!  or a new build tool.

Though this is a step I am not sure it is in the right direction.

Thanks for the lead though it was worth a try.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100816/63e2b970/attachment.htm>


More information about the CMake mailing list