I have merged the branch into next for you.
On Tue, Jan 6, 2015 at 6:50 PM, James Bigler 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
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 s
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 wro
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
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 me
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 wrote:
Okay, so I've gone and put the messages into FindCUDA.cmake. I specifically put
the
James
> On Jan 6, 2015, at 11:29 AM, Irwin Zaid 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 "$<$:-Xcompiler>;$<$:-f
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 "$<$:-Xcompiler>;$<$:-fPIC>" supposed to
be that way? That looks weird.
--
going to run COM
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. Ri
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
On Tue, Jan 6, 2015 at 8:54 AM, Irwin Zaid
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_RELEA
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_DE
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_SEPAR
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 i
On Mon, Jan 5, 2015 at 1:57 PM, Irwin Zaid
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
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
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
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,
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)",
19 matches
Mail list logo
