Re: [CMake] FindCUDA ignores project dependencies when separable compilation is on
I have merged the branch into next for you.
On Tue, Jan 6, 2015 at 6:50 PM, James Bigler jamesbig...@gmail.com wrote:
I've pushed a change into 'stage' [1] that I hope to get into 'next'
(something isn't working with my ssh authentication).
James
[1] commit b4e54f9b8c748f78d16e9da055a7e0436d7654ef
Author: James Bigler @
Date: Tue Jan 6 16:28:05 2015 -0700
FindCUDA: Add relevant CMAKE_{C,CXX}_FLAGS for separable compilation
Previously only the CMAKE_{C,CXX}_FLAGS_CONFIG flags were inspected
for relevant flags when compiling the intermediate link file. We need
to also consider the configuration agnostic flags, CMAKE_{C,CXX}_FLAGS
as well.
On Tue, Jan 6, 2015 at 4:29 PM, Irwin Zaid irwin.z...@physics.ox.ac.uk
wrote:
Okay, so to conclude:
Should we make a PR to include your patched code so CMAKE_CXX_FLAGS just
works? I think this makes sense, as I would never have thought to do the
DEBUG / RELEASE stuff. I can do the PR, unless you want to.
And, of course, thanks for all your help!
Irwin
James Bigler wrote:
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.z...@physics.ox.ac.uk
mailto:irwin.z...@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
Zaidirwin.z...@physics.ox.ac.__uk
mailto:irwin.z...@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
http://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
Re: [CMake] FindCUDA ignores project dependencies when separable compilation is on
James On Jan 6, 2015, at 11:29 AM, Irwin Zaid irwin.z...@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_dynd_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_dynd_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
Re: [CMake] FindCUDA ignores project dependencies when separable compilation is on
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 Zaidirwin.z...@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
Re: [CMake] FindCUDA ignores project dependencies when separable compilation is on
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.z...@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 Zaidirwin.z...@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
Re: [CMake] FindCUDA ignores project dependencies when separable compilation is on
Okay, so to conclude: Should we make a PR to include your patched code so CMAKE_CXX_FLAGS just works? I think this makes sense, as I would never have thought to do the DEBUG / RELEASE stuff. I can do the PR, unless you want to. And, of course, thanks for all your help! Irwin James Bigler wrote: 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.z...@physics.ox.ac.uk mailto:irwin.z...@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 Zaidirwin.z...@physics.ox.ac.__uk mailto:irwin.z...@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 http://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
Re: [CMake] FindCUDA ignores project dependencies when separable compilation is on
I've pushed a change into 'stage' [1] that I hope to get into 'next'
(something isn't working with my ssh authentication).
James
[1] commit b4e54f9b8c748f78d16e9da055a7e0436d7654ef
Author: James Bigler @
Date: Tue Jan 6 16:28:05 2015 -0700
FindCUDA: Add relevant CMAKE_{C,CXX}_FLAGS for separable compilation
Previously only the CMAKE_{C,CXX}_FLAGS_CONFIG flags were inspected
for relevant flags when compiling the intermediate link file. We need
to also consider the configuration agnostic flags, CMAKE_{C,CXX}_FLAGS
as well.
On Tue, Jan 6, 2015 at 4:29 PM, Irwin Zaid irwin.z...@physics.ox.ac.uk
wrote:
Okay, so to conclude:
Should we make a PR to include your patched code so CMAKE_CXX_FLAGS just
works? I think this makes sense, as I would never have thought to do the
DEBUG / RELEASE stuff. I can do the PR, unless you want to.
And, of course, thanks for all your help!
Irwin
James Bigler wrote:
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.z...@physics.ox.ac.uk
mailto:irwin.z...@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
Zaidirwin.z...@physics.ox.ac.__uk
mailto:irwin.z...@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
http://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
Re: [CMake] FindCUDA ignores project dependencies when separable compilation is on
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 Zaidirwin.z...@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_dy 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_dy 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
Re: [CMake] FindCUDA ignores project dependencies when separable compilation is on
Okay, an update on this.
1) This is fixed now, thank you. We just needed to add a custom target, as you
said.
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.
--
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()
James Bigler wrote:
2. It looks as though CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS is only
looking at the configuration specific flags. You can add the flag
specifically to all your configs (e.g. CMAKE_CXX_FLAGS_DEBUG) or you
could try adding these lines of code in your FindCUDA.cmake file
somewhere in CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS after set(flags).
It looks as though this was overlooked (sorry).
set(important_host_flags)
_cuda_get_important_host_flags(important_host_flags
${CMAKE_${CUDA_C_OR_CXX}_FLAGS})
foreach(f ${important_host_flags})
list(APPEND flags -Xcompiler ${f})
endforeach()
On Mon, Jan 5, 2015 at 3:43 PM, Irwin Zaid
irwin.z...@physics.ox.ac.uk mailto:irwin.z...@physics.ox.ac.uk wrote:
Alright, this is a lot of progress!
1) We are using Makefiles. I agree with you about the dependency
graph, so I'll try and sort that out. I'll let you know what the
result is.
2) I just checked and, indeed, the *_intermediate_link.o file is
not being passed -fPIC. Is this our problem? What is the correct fix?
Irwin
James Bigler wrote:
On Mon, Jan 5, 2015 at 1:57 PM, Irwin Zaid
irwin.z...@physics.ox.ac.uk mailto:irwin.z...@physics.ox.ac.uk
mailto:irwin.z...@physics.ox.__ac.uk
mailto:irwin.z...@physics.ox.ac.uk wrote:
Hi James,
Thanks for the quick reply! As I mentioned, we've hit two issues.
The first is the project dependencies one, which I'll try and
describe more a bit below. I'm not a CMake expert, so please bear
with me.
The second is what I've put under 2).
The only CMake build dependency changes when doing separable
compilation
are found in CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS.
Basically what
this does is create a new rule to build an intermediate link
file. For
everything but some versions of MSVC generators it adds a custom
command
to generate this intermediate link file. The other case adds a
custom
command that runs as a PRE_LINK command to generate the object
file (the
reasons for this is a bug in VS custom command dependency
scanning), but
this should happen during link phase and not compile phase.
Nothing in here should change what happens before the target is
built,
though.
1) Okay, I understand that, but I do think we saw a different
behaviour when we switched to separable compilation. Let me
describe
what we are doing.
We generate part of our library from a simple program (call the
simple program 'gen', which generates a source file 'gen.hpp')
that
we want to execute before compiling our library (call our library
'main'). We set this up with the following:
- add_executable(...) is called for 'gen'
- add_custom_command(...) sets up a command that executes 'gen'
- set_source_files_properties(...) is called to set
'gen.hpp' as
having the PROPERTY of GENERATED
- add_dependencies(main gen) is called to establish 'main' depends
on 'gen'
So far, this has only failed for CUDA with separable compilation.
(It has worked for all of our other configurations. including CUDA
without separable compilation.)
Have we done something wrong? Is there some additional information
we can look at to figure out what's going on?
What kind of generator are you using (e.g. makefile)?
Here's what I'm thinking might be the problem, though I'm not
sure why
it would have worked without CUDA_SEPARABLE_COMPILATION.
There's a dependency between gen and gen.hpp (encoded in the
call to
add_custom_command(OUTPUTS gen.hpp COMMAND gen)).
Re: [CMake] FindCUDA ignores project dependencies when separable compilation is on
On Tue, Jan 6, 2015 at 8:54 AM, Irwin Zaid irwin.z...@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})
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] FindCUDA ignores project dependencies when separable compilation is on
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.z...@physics.ox.ac.uk mailto:irwin.z...@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})
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] FindCUDA ignores project dependencies when separable compilation is on
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.z...@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.z...@physics.ox.ac.uk
mailto:irwin.z...@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})
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] FindCUDA ignores project dependencies when separable compilation is on
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.
--
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_dynd_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_dynd_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.z...@physics.ox.ac.uk
mailto:irwin.z...@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.z...@physics.ox.ac.uk
Re: [CMake] FindCUDA ignores project dependencies when separable compilation is on
Just wanted to send this again, as the problem still exists. While working on the libdynd project (https://github.com/libdynd/libdynd), we've discovered two CUDA CMake issues that we'd like to help resolve. Who are the right people to speak with about these? Irwin Irwin Zaid wrote: Hi all, Just wanted to mention this issue I've run into. I have a project (libdynd -- https://github.com/libdynd/libdynd) that uses FindCUDA to deal with CUDA compilation. A part of our library is generated at compile-time, which we handle by the command add_dependencies(libdynd some_exe), where some_exe is an executable built with a custom command. This part of our library needs to be present before anything else is built. So far, everything has worked great, with and without CUDA. However, I found that by just turning separable compilation on, via set(CUDA_SEPARABLE_COMPILATION ON), the dependency I've added is then ignored and the necessary files are not generated. Basically, CMake goes straight to NVCC without running the custom command. This seems to me to be something wrong with FindCUDA, but it is of course possible that I've done something wrong. Any help would be appreciated! Irwin -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] FindCUDA ignores project dependencies when separable compilation is on
On Mon, Jan 5, 2015 at 1:57 PM, Irwin Zaid irwin.z...@physics.ox.ac.uk wrote: Hi James, Thanks for the quick reply! As I mentioned, we've hit two issues. The first is the project dependencies one, which I'll try and describe more a bit below. I'm not a CMake expert, so please bear with me. The second is what I've put under 2). The only CMake build dependency changes when doing separable compilation are found in CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS. Basically what this does is create a new rule to build an intermediate link file. For everything but some versions of MSVC generators it adds a custom command to generate this intermediate link file. The other case adds a custom command that runs as a PRE_LINK command to generate the object file (the reasons for this is a bug in VS custom command dependency scanning), but this should happen during link phase and not compile phase. Nothing in here should change what happens before the target is built, though. 1) Okay, I understand that, but I do think we saw a different behaviour when we switched to separable compilation. Let me describe what we are doing. We generate part of our library from a simple program (call the simple program 'gen', which generates a source file 'gen.hpp') that we want to execute before compiling our library (call our library 'main'). We set this up with the following: - add_executable(...) is called for 'gen' - add_custom_command(...) sets up a command that executes 'gen' - set_source_files_properties(...) is called to set 'gen.hpp' as having the PROPERTY of GENERATED - add_dependencies(main gen) is called to establish 'main' depends on 'gen' So far, this has only failed for CUDA with separable compilation. (It has worked for all of our other configurations. including CUDA without separable compilation.) Have we done something wrong? Is there some additional information we can look at to figure out what's going on? What kind of generator are you using (e.g. makefile)? Here's what I'm thinking might be the problem, though I'm not sure why it would have worked without CUDA_SEPARABLE_COMPILATION. There's a dependency between gen and gen.hpp (encoded in the call to add_custom_command(OUTPUTS gen.hpp COMMAND gen)). There's a dependency between main and gen (can't start building main until gen is built). There's a dependency between gen.hpp and main (gen.hpp is an input source to main, so it needs to be built as part of main). What I don't see is a dependency between gen.hpp and all the cuda sources that might use it as input. So from a dependency graph standpoint a makefile (if one is being used in this case) is entirely free to start compiling the CUDA code once the gen target has been satisfied. What you need is another target that builds the gen.hpp file which can be forced to run before main starts to build. There are more than one way to do this, and I'm not sure what the best option is, but you might try this: add_custom_command(OUTPUTS gen.hpp ) add_custom_target(make_gen_hpp DEPENDS gen.hpp) add_dependency(main make_gen_hpp) 2) A second problem we've run into is an error when trying to link a CUDA shared library with separable compilation. This is specifically a Linux problem, on Mac it is fine. A static library is also fine, working for both Linux and Mac. The particular error is relocation R_X86_64_32S against `__nv_module_id' can not be used when making a shared object; recompile with -fPIC. However, we are already compiling with -fPIC. I can confirm that -fPIC appears to be passed to both the host compiler for non-CUDA source and via -Xcompiler -fPIC for CUDA source. This error occurs when trying to link all the different object files together of our library. Do you have any idea of what this could be? I'm not sure which object file wasn't compiled with -fPIC, but I would suspect it might be the intermediate link object file. FindCUDA is supposed to pass this flag along (see function(_cuda_get_important_host_flags)), but you might want to verify this with a 'make VERBOSE=1' and look for target_name_intermediate_link.o (substitute your target name in or leave it out of the search string). James -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] FindCUDA ignores project dependencies when separable compilation is on
Alright, this is a lot of progress! 1) We are using Makefiles. I agree with you about the dependency graph, so I'll try and sort that out. I'll let you know what the result is. 2) I just checked and, indeed, the *_intermediate_link.o file is not being passed -fPIC. Is this our problem? What is the correct fix? Irwin James Bigler wrote: On Mon, Jan 5, 2015 at 1:57 PM, Irwin Zaid irwin.z...@physics.ox.ac.uk mailto:irwin.z...@physics.ox.ac.uk wrote: Hi James, Thanks for the quick reply! As I mentioned, we've hit two issues. The first is the project dependencies one, which I'll try and describe more a bit below. I'm not a CMake expert, so please bear with me. The second is what I've put under 2). The only CMake build dependency changes when doing separable compilation are found in CUDA_LINK_SEPARABLE___COMPILATION_OBJECTS. Basically what this does is create a new rule to build an intermediate link file. For everything but some versions of MSVC generators it adds a custom command to generate this intermediate link file. The other case adds a custom command that runs as a PRE_LINK command to generate the object file (the reasons for this is a bug in VS custom command dependency scanning), but this should happen during link phase and not compile phase. Nothing in here should change what happens before the target is built, though. 1) Okay, I understand that, but I do think we saw a different behaviour when we switched to separable compilation. Let me describe what we are doing. We generate part of our library from a simple program (call the simple program 'gen', which generates a source file 'gen.hpp') that we want to execute before compiling our library (call our library 'main'). We set this up with the following: - add_executable(...) is called for 'gen' - add_custom_command(...) sets up a command that executes 'gen' - set_source_files_properties(..__.) is called to set 'gen.hpp' as having the PROPERTY of GENERATED - add_dependencies(main gen) is called to establish 'main' depends on 'gen' So far, this has only failed for CUDA with separable compilation. (It has worked for all of our other configurations. including CUDA without separable compilation.) Have we done something wrong? Is there some additional information we can look at to figure out what's going on? What kind of generator are you using (e.g. makefile)? Here's what I'm thinking might be the problem, though I'm not sure why it would have worked without CUDA_SEPARABLE_COMPILATION. There's a dependency between gen and gen.hpp (encoded in the call to add_custom_command(OUTPUTS gen.hpp COMMAND gen)). There's a dependency between main and gen (can't start building main until gen is built). There's a dependency between gen.hpp and main (gen.hpp is an input source to main, so it needs to be built as part of main). What I don't see is a dependency between gen.hpp and all the cuda sources that might use it as input. So from a dependency graph standpoint a makefile (if one is being used in this case) is entirely free to start compiling the CUDA code once the gen target has been satisfied. What you need is another target that builds the gen.hpp file which can be forced to run before main starts to build. There are more than one way to do this, and I'm not sure what the best option is, but you might try this: add_custom_command(OUTPUTS gen.hpp ) add_custom_target(make_gen_hpp DEPENDS gen.hpp) add_dependency(main make_gen_hpp) 2) A second problem we've run into is an error when trying to link a CUDA shared library with separable compilation. This is specifically a Linux problem, on Mac it is fine. A static library is also fine, working for both Linux and Mac. The particular error is relocation R_X86_64_32S against `__nv_module_id' can not be used when making a shared object; recompile with -fPIC. However, we are already compiling with -fPIC. I can confirm that -fPIC appears to be passed to both the host compiler for non-CUDA source and via -Xcompiler -fPIC for CUDA source. This error occurs when trying to link all the different object files together of our library. Do you have any idea of what this could be? I'm not sure which object file wasn't compiled with -fPIC, but I would suspect it might be the intermediate link object file. FindCUDA is supposed to pass this flag along (see function(_cuda_get_important_host_flags)), but you might want to verify this with a 'make VERBOSE=1' and look for target_name_intermediate_link.o (substitute your target name in or leave it out of the search string). James -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers
Re: [CMake] FindCUDA ignores project dependencies when separable compilation is on
2. It looks as though CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS is only
looking at the configuration specific flags. You can add the flag
specifically to all your configs (e.g. CMAKE_CXX_FLAGS_DEBUG) or you could
try adding these lines of code in your FindCUDA.cmake file somewhere
in CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS after set(flags). It looks as
though this was overlooked (sorry).
set(important_host_flags)
_cuda_get_important_host_flags(important_host_flags
${CMAKE_${CUDA_C_OR_CXX}_FLAGS})
foreach(f ${important_host_flags})
list(APPEND flags -Xcompiler ${f})
endforeach()
On Mon, Jan 5, 2015 at 3:43 PM, Irwin Zaid irwin.z...@physics.ox.ac.uk
wrote:
Alright, this is a lot of progress!
1) We are using Makefiles. I agree with you about the dependency graph, so
I'll try and sort that out. I'll let you know what the result is.
2) I just checked and, indeed, the *_intermediate_link.o file is not being
passed -fPIC. Is this our problem? What is the correct fix?
Irwin
James Bigler wrote:
On Mon, Jan 5, 2015 at 1:57 PM, Irwin Zaid irwin.z...@physics.ox.ac.uk
mailto:irwin.z...@physics.ox.ac.uk wrote:
Hi James,
Thanks for the quick reply! As I mentioned, we've hit two issues.
The first is the project dependencies one, which I'll try and
describe more a bit below. I'm not a CMake expert, so please bear
with me.
The second is what I've put under 2).
The only CMake build dependency changes when doing separable
compilation
are found in CUDA_LINK_SEPARABLE___COMPILATION_OBJECTS.
Basically what
this does is create a new rule to build an intermediate link
file. For
everything but some versions of MSVC generators it adds a custom
command
to generate this intermediate link file. The other case adds a
custom
command that runs as a PRE_LINK command to generate the object
file (the
reasons for this is a bug in VS custom command dependency
scanning), but
this should happen during link phase and not compile phase.
Nothing in here should change what happens before the target is
built,
though.
1) Okay, I understand that, but I do think we saw a different
behaviour when we switched to separable compilation. Let me describe
what we are doing.
We generate part of our library from a simple program (call the
simple program 'gen', which generates a source file 'gen.hpp') that
we want to execute before compiling our library (call our library
'main'). We set this up with the following:
- add_executable(...) is called for 'gen'
- add_custom_command(...) sets up a command that executes 'gen'
- set_source_files_properties(..__.) is called to set 'gen.hpp' as
having the PROPERTY of GENERATED
- add_dependencies(main gen) is called to establish 'main' depends
on 'gen'
So far, this has only failed for CUDA with separable compilation.
(It has worked for all of our other configurations. including CUDA
without separable compilation.)
Have we done something wrong? Is there some additional information
we can look at to figure out what's going on?
What kind of generator are you using (e.g. makefile)?
Here's what I'm thinking might be the problem, though I'm not sure why
it would have worked without CUDA_SEPARABLE_COMPILATION.
There's a dependency between gen and gen.hpp (encoded in the call to
add_custom_command(OUTPUTS gen.hpp COMMAND gen)).
There's a dependency between main and gen (can't start building main
until gen is built).
There's a dependency between gen.hpp and main (gen.hpp is an input
source to main, so it needs to be built as part of main).
What I don't see is a dependency between gen.hpp and all the cuda
sources that might use it as input. So from a dependency graph
standpoint a makefile (if one is being used in this case) is entirely
free to start compiling the CUDA code once the gen target has been
satisfied.
What you need is another target that builds the gen.hpp file which can
be forced to run before main starts to build. There are more than one
way to do this, and I'm not sure what the best option is, but you might
try this:
add_custom_command(OUTPUTS gen.hpp )
add_custom_target(make_gen_hpp DEPENDS gen.hpp)
add_dependency(main make_gen_hpp)
2) A second problem we've run into is an error when trying to link a
CUDA shared library with separable compilation. This is specifically
a Linux problem, on Mac it is fine. A static library is also fine,
working for both Linux and Mac.
The particular error is relocation R_X86_64_32S against
`__nv_module_id' can not be used when making a shared object;
recompile with -fPIC. However, we are already compiling with -fPIC.
I can confirm that -fPIC appears to be passed to both the host
Re: [CMake] FindCUDA ignores project dependencies when separable compilation is on
The only CMake build dependency changes when doing separable compilation are found in CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS. Basically what this does is create a new rule to build an intermediate link file. For everything but some versions of MSVC generators it adds a custom command to generate this intermediate link file. The other case adds a custom command that runs as a PRE_LINK command to generate the object file (the reasons for this is a bug in VS custom command dependency scanning), but this should happen during link phase and not compile phase. Nothing in here should change what happens before the target is built, though. On Mon, Jan 5, 2015 at 5:32 AM, Irwin Zaid irwin.z...@physics.ox.ac.uk wrote: Just wanted to send this again, as the problem still exists. While working on the libdynd project (https://github.com/libdynd/libdynd), we've discovered two CUDA CMake issues that we'd like to help resolve. Who are the right people to speak with about these? Irwin Irwin Zaid wrote: Hi all, Just wanted to mention this issue I've run into. I have a project (libdynd -- https://github.com/libdynd/libdynd) that uses FindCUDA to deal with CUDA compilation. A part of our library is generated at compile-time, which we handle by the command add_dependencies(libdynd some_exe), where some_exe is an executable built with a custom command. This part of our library needs to be present before anything else is built. So far, everything has worked great, with and without CUDA. However, I found that by just turning separable compilation on, via set(CUDA_SEPARABLE_COMPILATION ON), the dependency I've added is then ignored and the necessary files are not generated. Basically, CMake goes straight to NVCC without running the custom command. This seems to me to be something wrong with FindCUDA, but it is of course possible that I've done something wrong. Any help would be appreciated! Irwin -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/ opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] FindCUDA ignores project dependencies when separable compilation is on
Hi James, Thanks for the quick reply! As I mentioned, we've hit two issues. The first is the project dependencies one, which I'll try and describe more a bit below. I'm not a CMake expert, so please bear with me. The second is what I've put under 2). The only CMake build dependency changes when doing separable compilation are found in CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS. Basically what this does is create a new rule to build an intermediate link file. For everything but some versions of MSVC generators it adds a custom command to generate this intermediate link file. The other case adds a custom command that runs as a PRE_LINK command to generate the object file (the reasons for this is a bug in VS custom command dependency scanning), but this should happen during link phase and not compile phase. Nothing in here should change what happens before the target is built, though. 1) Okay, I understand that, but I do think we saw a different behaviour when we switched to separable compilation. Let me describe what we are doing. We generate part of our library from a simple program (call the simple program 'gen', which generates a source file 'gen.hpp') that we want to execute before compiling our library (call our library 'main'). We set this up with the following: - add_executable(...) is called for 'gen' - add_custom_command(...) sets up a command that executes 'gen' - set_source_files_properties(...) is called to set 'gen.hpp' as having the PROPERTY of GENERATED - add_dependencies(main gen) is called to establish 'main' depends on 'gen' So far, this has only failed for CUDA with separable compilation. (It has worked for all of our other configurations. including CUDA without separable compilation.) Have we done something wrong? Is there some additional information we can look at to figure out what's going on? 2) A second problem we've run into is an error when trying to link a CUDA shared library with separable compilation. This is specifically a Linux problem, on Mac it is fine. A static library is also fine, working for both Linux and Mac. The particular error is relocation R_X86_64_32S against `__nv_module_id' can not be used when making a shared object; recompile with -fPIC. However, we are already compiling with -fPIC. I can confirm that -fPIC appears to be passed to both the host compiler for non-CUDA source and via -Xcompiler -fPIC for CUDA source. This error occurs when trying to link all the different object files together of our library. Do you have any idea of what this could be? -- Thanks for all of your help. Cheers, Irwin -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
