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

[James Bigler]

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

> 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.  ....
> --end snip
>
> I tried it enable/disabling the flag again just to be sure I was seeing
> correct output.
>
>
> with CUDA_ATTACH_VS_BUILD_RULE_TO_CUDA_FILE ON (default - with my set line
> below commented out) and using the following:
>
> i get
>
> --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_11 --ptxas-options=-v -maxrregcount=32 -Xcompiler
> /EHsc,/W3,/nologo,/Od,/Zi,/MTd -DCUDADeviceProperties_DLLExport=yes
> -DGPU_RECON=yes -m64 -DgpuReconPlugin_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/gpuReconPlugin_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--
>
>
> with it off (set line uncommented in) I get
>
> --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_11 --ptxas-options=-v -maxrregcount=32 -Xcompiler
> /EHsc,/W3,/nologo,/Od,/Zi,/MTd -DCUDADeviceProperties_DLLExport=yes
> -DCPU_RECON=yes -m64 -DcpuReconPlugin_EXPORTS -ccbin "c:/Program Files
> (x86)/Microsoft Visual Studio 9.0/VC/bin" -DNVCC -c -o
> C:/Users/bdavis5/Documents/QS/QS-NIH/source/branches/trunk/build/dvip4-Win64/source/Matlab/lib/3rdParty/Siemens/gpu/PMatrixRecon/Debug/cpuReconPlugin_generated_gpuPMatrixRecon.cu.obj
> -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--
>
> Which is what (I think) I desire... unless there is something else I am not
> aware of.
>
> I am reporting what I am seeing.  I have modified FindCUDA, but only with
> messages so I can see what it is doing.  I have not changed the
> functionality of FindCUDA at all.
>
>
You are getting the correct output.  Look at the flags and target files more
closely:

-DGPU_RECON=yes -m64 -DgpuReconPlugin_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/
gpuReconPlugin_generated_gpuPMatrixRecon.cu.obj.NVCC-depend

 -DCPU_RECON=yes -m64 -DcpuReconPlugin_EXPORTS -ccbin "c:/Program Files
(x86)/Microsoft Visual Studio 9.0/VC/bin" -DNVCC -c -o
C:/Users/bdavis5/Documents/QS/QS-NIH/source/branches/trunk/build/dvip4-Win64/source/Matlab/lib/3rdParty/Siemens/gpu/PMatrixRecon/Debug/
cpuReconPlugin_generated_gpuPMatrixRecon.cu.obj

The problem is that there are two rules to build from gpuPMatrixRecon.cu.
One builds the cpu version and one builds the gpu version.  This is because
when CUDA_ATTACH_VS_BUILD_RULE_TO_CUDA_FILE is true, VS attaches a single
build rule to that file.  CMake sees this, and realizes there needs to be a
build rule for the other and adds the cmake_rules file.  See project2 from
my previous post.  It will build both versions of the file.

Anyway, you should be turning that off if you are reusing the same file in
muliple projects in the same directory like you are doing.



> I am not parallel building so I do not think it is a problem.  As far as
> the race to build project1_myfile.cu.obj I do not appear to be experiencing
> this (as I am not parallel building).  I don't think I am experiencing the
> linear build issue as it appears that if I select each lib which has the .cu
> file and select rebuild... that each lib gets rebuilt as expected.  I did
> look for this issue based on the CMake FindCUDA documentation.  This may be
> related to the following output goop at msvc compiler window:
>
> --snip--
> Generating temporary cmake readable file:
> C:/Users/bdavis5/Documents/QS/QS-NIH/source/branches/trunk/build/dvip4-Win64/source/Matlab/lib/3rdParty/Siemens/gpu/PMatrixRecon/CMakeFiles/gpuReconPlugin_generated_gpuPMatrixRecon.cu.obj.depend.tmp
> --end snip--
>
>
This is FindCUDA generating the dependency file using nvcc.


> Note the prefix gpuReconPlugin and tmp possibly referring to a temporary
> file with the .obj sandwiched in between.  It's a Cuda, CMake, obj
> sandwich.  Mmmmm add pickles and a little mayo and it's tasty.  I should
> coin this term and open up a Techno Deli :-)
>
>
Yup, I just build file names by appending/prepending things:
<target>_generated_<filename>.<target_type>.depend.tmp.  The .depend file is
the dependency file used to track dependencies, and the tmp version is what
nvcc generates.  I then use a copy_if_different command, so that the
dependency file only gets its timestamp updated if it actually changes.  GCC
-M only writes to the dependency file if it changes, but nvcc -M always
write to it, so I have to emulate this behavior myself.


> --snip--
> Incidentally, 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.
> --end snip--
>
> Yes.... and my reply to this is a restatement of above.
>
> --snip--
> Have I mentioned to anyone lately why I can't understand CMake's (poor)
> design choice in correlating directory structure to target build
> specification. It would appear to me from this (if unmodified) that I must
> create a new directory in order to get CMake to build 2 dlls in the same
> directory based on the same source using different compiler defined.   I
> have reached a state of boondogglement.
> --end snip--
>
> Why was this a design decision on CMake's part?
>
>
This is probably historical reasons.  It's been that way as long as I've
been using CMake (since v. 1.6).


> --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.
> --end snip--
>
> I read through the FindCUDA source and thought this was how I should
> specify this.  Output of my messages in FindCUDA supported the use of this
> syntax:
>
>
OK, specify the same flags for all the configurations isn't wrong, per se,
but it is overly verbose.  Any flags you want applied to all configurations
can be placed directly after the OPTIONS flag and before any configuration
specific options.  CMake has CMAKE_CXX_FLAGS that get applied to all CXX
files, and CMAKE_CXX_FLAGS_<CONFIG> that get applied only in the specified
configuration.  This is mirrored in the options:

OPTIONS <all config options>
DEBUG <debug config options>
RELEASE <release config options>
...

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