[CMake] FindCUDA ignores project dependencies when separable compilation is on

James Bigler jamesbigler at gmail.com
Tue Jan 6 18:14:25 EST 2015 

Right, if you don't specify the CMAKE_BUILD_TYPE you are only getting the
CMAKE_CXX_FLAGS and none of the build type specific flags such as
CMAKE_CXX_FLAGS_DEBUG.

There is still the issue that I wasn't bringing in the CMAKE_CXX_FLAGS
(which is why my patch helped).

James

On Tue, Jan 6, 2015 at 1:32 PM, Irwin Zaid <irwin.zaid at physics.ox.ac.uk>
wrote:

> Wait, hold on. The -fPIC does get passed to everything if I set the build
> mode to Debug by passing -DCMAKE_BUILD_TYPE=Debug to CMake. Is that what I
> should be doing? (Sorry about that, if yes.)
>
> If that's the case, what is the correct way to get -fPIC passed to the
> intermediate linking? Am I meant to always build in Debug mode just for
> that?
>
> Irwin
>
> Irwin Zaid wrote:
>
>> I just double-checked. The -fPIC is definitely there for each individual
>> object file, but not for the *_intermediate_link.o.
>>
>> Irwin
>>
>> James Bigler wrote:
>>
>>>
>>> James
>>>
>>>  On Jan 6, 2015, at 11:29 AM, Irwin Zaid<irwin.zaid at physics.ox.ac.uk>
>>>>  wrote:
>>>>
>>>> Okay, so I've gone and put the messages into FindCUDA.cmake. I
>>>> specifically put them right before and after the foreach() in
>>>> CUDA_LINK_SEPARARABLE_COMPILATION_OBJECTS. The output is the following.
>>>>
>>>> Is "$<$<CONFIG:Debug>:-Xcompiler>;$<$<CONFIG:Debug>:-fPIC>" supposed
>>>> to be that way? That looks weird.
>>>>
>>>>  Yeah. That looks right. It means the argument will only be run when
>>> the build configuration matches DEBUG. This is less exciting for Makefiles
>>> builds since there is only one configuration preset at a time, but for
>>> things like Visual Studio where you have multiple build configs from a
>>> single CMake configure this makes a custom command for each without having
>>> to rely on scripts to dispatch the correct command (that's how the rest of
>>> FindCUDA works by the way).
>>>
>>> As far as the rest of these, I'm concerned the fPIC flag comes and goes.
>>> Perhaps something is modifying the flags. Do the commands with fPIC
>>> actually get run with fPIC (use make VERBOSE=1)?
>>>
>>>  --
>>>>
>>>> going to run COMMAND /usr/local/cuda/bin/nvcc -m64;-ccbin;"/usr/bin/cc"
>>>> -dlink /home/irwin/Repositories/libdynd/build/CMakeFiles/
>>>> libdynd.dir/src/dynd/kernels/./libdynd_generated_assignment_
>>>> kernels.cu.o;/home/irwin/Repositories/libdynd/build/
>>>> CMakeFiles/libdynd.dir/src/dynd/func/./libdynd_generated_
>>>> arithmetic.cu.o;/home/irwin/Repositories/libdynd/build/
>>>> CMakeFiles/libdynd.dir/src/dynd/func/./libdynd_generated_
>>>> elwise.cu.o;/home/irwin/Repositories/libdynd/build/
>>>> CMakeFiles/libdynd.dir/src/dynd/kernels/./libdynd_
>>>> generated_ckernel_builder.cu.o;/home/irwin/Repositories/
>>>> libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./
>>>> libdynd_generated_dynd_complex.cu.o;/home/irwin/
>>>> Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/
>>>> dynd/types/./libdynd_generated_dynd_float16.cu.o;/
>>>> home/irwin/Repositories/libdynd/build/CMakeFiles/
>>>> libdynd.dir/src/dynd/types/./libdynd_generated_dynd_
>>>> float128.cu.o;/home/irwin/Repositories/libdynd/build/
>>>> CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_d
>>>>
>>> y
>
>> nd_int128.cu.o;/home/irwin/Repositories/libdynd/build/
>> CMakeFiles/libdynd.dir/src/d
>>
>>> ynd/types/./libdynd_generated_dynd_uint128.cu.o -o
>>>> /home/irwin/Repositories/libdynd/build/CMakeFiles/
>>>> libdynd.dir/./libdynd_intermediate_link.o
>>>>
>>>> going to run COMMAND /usr/local/cuda/bin/nvcc -m64;-ccbin;"/usr/bin/cc"
>>>> -dlink /home/irwin/Repositories/libdynd/build/CMakeFiles/
>>>> libdynd.dir/src/dynd/kernels/./libdynd_generated_assignment_
>>>> kernels.cu.o;/home/irwin/Repositories/libdynd/build/
>>>> CMakeFiles/libdynd.dir/src/dynd/func/./libdynd_generated_
>>>> arithmetic.cu.o;/home/irwin/Repositories/libdynd/build/
>>>> CMakeFiles/libdynd.dir/src/dynd/func/./libdynd_generated_
>>>> elwise.cu.o;/home/irwin/Repositories/libdynd/build/
>>>> CMakeFiles/libdynd.dir/src/dynd/kernels/./libdynd_
>>>> generated_ckernel_builder.cu.o;/home/irwin/Repositories/
>>>> libdynd/build/CMakeFiles/libdynd.dir/src/dynd/types/./
>>>> libdynd_generated_dynd_complex.cu.o;/home/irwin/
>>>> Repositories/libdynd/build/CMakeFiles/libdynd.dir/src/
>>>> dynd/types/./libdynd_generated_dynd_float16.cu.o;/
>>>> home/irwin/Repositories/libdynd/build/CMakeFiles/
>>>> libdynd.dir/src/dynd/types/./libdynd_generated_dynd_
>>>> float128.cu.o;/home/irwin/Repositories/libdynd/build/
>>>> CMakeFiles/libdynd.dir/src/dynd/types/./libdynd_generated_d
>>>>
>>> y
>
>> nd_int128.cu.o;/home/irwin/Repositories/libdynd/build/
>> CMakeFiles/libdynd.dir/src/d
>>
>>> ynd/types/./libdynd_generated_dynd_uint128.cu.o -o
>>>> /home/irwin/Repositories/libdynd/build/CMakeFiles/
>>>> libdynd.dir/./libdynd_intermediate_link.o
>>>> $<$<CONFIG:Debug>:-Xcompiler>;$<$<CONFIG:Debug>:-fPIC>
>>>> going to run COMMAND /usr/local/cuda/bin/nvcc -m64;-ccbin;"/usr/bin/cc"
>>>> -dlink /home/irwin/Repositories/libdynd/build/tests/
>>>> CMakeFiles/test_libdynd.dir/func/./test_libdynd_generated_
>>>> test_apply.cu.o;/home/irwin/Repositories/libdynd/build/
>>>> tests/CMakeFiles/test_libdynd.dir/func/./test_libdynd_
>>>> generated_test_lift_arrfunc.cu.o -o /home/irwin/Repositories/
>>>> libdynd/build/tests/CMakeFiles/test_libdynd.dir/./
>>>> test_libdynd_intermediate_link.o
>>>>
>>>> going to run COMMAND /usr/local/cuda/bin/nvcc -m64;-ccbin;"/usr/bin/cc"
>>>> -dlink /home/irwin/Repositories/libdynd/build/tests/
>>>> CMakeFiles/test_libdynd.dir/func/./test_libdynd_generated_
>>>> test_apply.cu.o;/home/irwin/Repositories/libdynd/build/
>>>> tests/CMakeFiles/test_libdynd.dir/func/./test_libdynd_
>>>> generated_test_lift_arrfunc.cu.o -o /home/irwin/Repositories/
>>>> libdynd/build/tests/CMakeFiles/test_libdynd.dir/./
>>>> test_libdynd_intermediate_link.o $<$<CONFIG:Debug>:-Xcompiler>;
>>>> $<$<CONFIG:Debug>:-fPIC>
>>>>
>>>> James Bigler wrote:
>>>>
>>>>> I meant putting messages into FindCUDA.cmake itself.
>>>>>
>>>>> Only certain flags are propagated for the intermediate link file
>>>>> compilation, because I've had a lot of trouble over the years for
>>>>> propagating all the host flags. This set of flags is filtered by the
>>>>> function _cuda_get_important_host_flags. Right now only the
>>>>> CMAKE_CXX_FLAGS_*CONFIG* are being processed. None of the flags in the
>>>>> configuration free variable are passed. That was the "patch" I wanted
>>>>> you to try. Why -fPIC in the configuration specific CMAKE_CXX_FLAGS
>>>>> wasn't working, I'm not sure. The code is there to do it.
>>>>>
>>>>> On Tue, Jan 6, 2015 at 10:05 AM, Irwin Zaid<irwin.zaid at physics.ox.ac.
>>>>> uk
>>>>> <mailto:irwin.zaid at physics.ox.ac.uk>>   wrote:
>>>>>
>>>>>      Right, when I modify FindCUDA.cmake as you describe everything
>>>>>      works. So that's good.
>>>>>
>>>>>      Without doing that, I still don't see CMAKE_CXX_FLAGS_DEBUG
>>>>>      propagating its flags to the intermediate link file. Did you mean
>>>>> to
>>>>>      put message commands into CUDA_LINK_SEPARABLE___
>>>>> COMPILATION_OBJECTS
>>>>>      itself? When I put them into my main CMakeLists.txt, nothing is
>>>>>      printed for ${nvcc_flags} or the other variables.
>>>>>
>>>>>      James Bigler wrote:
>>>>>
>>>>>          On Tue, Jan 6, 2015 at 8:54 AM, Irwin Zaid
>>>>>          <irwin.zaid at physics.ox.ac.uk
>>>>>          <mailto:irwin.zaid at physics.ox.ac.uk>
>>>>>          <mailto:irwin.zaid at physics.ox.__ac.uk
>>>>>          <mailto:irwin.zaid at physics.ox.ac.uk>>>   wrote:
>>>>>
>>>>>          Okay, an update on this.
>>>>>
>>>>>          2) This is trickier and, unfortunately, still not working. We
>>>>> are
>>>>>          already adding -fPIC to CMAKE_CXX_FLAGS, should that not be
>>>>>          enough? I also tried adding it to both CMAKE_CXX_FLAGS_DEBUG
>>>>> and
>>>>>          CMAKE_CXX_FLAGS_RELEASE, with no effect.
>>>>>
>>>>>          Looking into FindCUDA.CMake at
>>>>>          CUDA_LINK_SEPARABLE_____COMPILATION_OBJECTS, I find code very
>>>>>          similar to what you are describing. Are you saying that in
>>>>>          addition to what is below, we need to add what you proposed?
>>>>> This
>>>>>          is what I see.
>>>>>
>>>>>          --
>>>>>
>>>>>
>>>>>          It can be put here (before this foreach).
>>>>>
>>>>>          foreach(config ${CUDA_configuration_types})
>>>>>          string(TOUPPER ${config} config_upper)
>>>>>          # Add config specific flags
>>>>>          foreach(f ${CUDA_NVCC_FLAGS_${config_____upper}})
>>>>>          list(APPEND config_specific_flags $<$<CONFIG:${config}>:${f}>)
>>>>>          endforeach()
>>>>>          set(important_host_flags)
>>>>>          _cuda_get_important_host_____flags(important_host_flags
>>>>>          ${CMAKE_${CUDA_C_OR_CXX}_____FLAGS_${config_upper}})
>>>>>          foreach(f ${important_host_flags})
>>>>>          list(APPEND flags $<$<CONFIG:${config}>:-____Xcompiler>
>>>>>          $<$<CONFIG:${config}>:${f}>)
>>>>>          endforeach()
>>>>>          endforeach()
>>>>>
>>>>>
>>>>>          Or it can be put here (or after the foreach).
>>>>>
>>>>>          I'm concerned that the flag didn't show up after adding it to
>>>>>          the _DEBUG or _RELEASE variants. If you could add a few
>>>>> message
>>>>>          commands around that might help see what is going on. The flag
>>>>>          needs to be propagated.
>>>>>
>>>>>          You could sprinkle a few commands like this:
>>>>>          message("going to run COMMAND ${CUDA_NVCC_EXECUTABLE}
>>>>>          ${nvcc_flags} -dlink ${object_files} -o ${output_file}
>>>>>          ${flags}")
>>>>>
>>>>>
>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20150106/43507a1a/attachment-0001.html>

More information about the CMake mailing list