On Tue, Aug 17, 2010 at 9:08 AM, Brian Davis bitmi...@gmail.com wrote:
I am and it is working. It is not clear to me still why it would be a
problem with parallel builds due to the target object naming convention you
have used as stated in:
--snip --
Yup, I just build file names by
From my current research into this problem it looks like the issue can be
traced to these lines in FindCuda.cmake
--snip--
# Get the list of definitions from the directory property
get_directory_property(CUDA_NVCC_DEFINITIONS COMPILE_DEFINITIONS)
message( CUDA_NVCC_DEFINITIONS =
On Mon, Aug 16, 2010 at 12:21 PM, Brian Davis bitmi...@gmail.com wrote:
From my current research into this problem it looks like the issue can be
traced to these lines in FindCuda.cmake
--snip--
# Get the list of definitions from the directory property
James I was going to cc you on my latest findings. Thanks for giving me a
way out with out having to patch the FindCUDA. I recently came to the
same conclusion as your recent post.
1. CUDA_ATTACH_VS_BUILD_RULE_TO_
CUDA_FILE can really only cause problems with parallel builds. Are you
One more thing for thoes interested DEFINITIONS_STRING is set in the
following manner:
--snip--
set( DEFINITIONS_STRING )
foreach( DEFINE_STR ${ARG_DEFINES} )
set( DEFINITIONS_STRING ${DEFINITIONS_STRING} -D${DEFINE_STR} )
endforeach()
--end snip--
On Mon, Aug 16, 2010 at 2:17 PM, Brian Davis bitmi...@gmail.com wrote:
James I was going to cc you on my latest findings. Thanks for giving me a
way out with out having to patch the FindCUDA. I recently came to the
same conclusion as your recent post.
I just noticed your email in my
I just noticed your email in my FindCUDA filter from the CMake list. I'm
not sure why it didn't show up sooner.
No worries. I let this thread die for a while while I worked on other
things. I was back recently trying to fix this issue as I now want to
compare the cpu/gpu recons separately. I
On Mon, Aug 16, 2010 at 4:21 PM, Brian Davis bitmi...@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
Shouldn't this be COMPILE_FLAGS?
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_dir:COMPILE_DEFINITIONS
Under properties on directories
Preprocessor definitions for compiling a directory's sources.
The COMPILE_DEFINITIONS property may be set to a semicolon-separated list of
processor
--snip--
Ah you're on windows, make sure that you deselect the option to
associate the build rule with cu files as this does the wrong thing
when you're compiling the same file multiple times with different
defines.
--end snip--
Can you give me more info on this? I have looked in CMake variables
I have a macro which gets called to create cuda and matlab mex enabled
libraries and apps. I call this macro **twice from within a single
directory** to create 2 libraries. Problem is that I desire to set compiler
defines -DWHATEVER=goop etc differently for each lib (for each of the two in
Try changing your macro into a function instead.
James
On 14/07/2010, Brian Davis bitmi...@gmail.com wrote:
I have a macro which gets called to create cuda and matlab mex enabled
libraries and apps. I call this macro **twice from within a single
directory** to create 2 libraries. Problem is
Try changing your macro into a function instead.
I did try as you suggest and it works exactly the same as if it were a
macro.
From my cmake gui output debug messages the macro or function is seeing the
CPU_RECON and GPU_RECON.
ARG_SRCDIRS =
ARG_CPP_SOURCES =
Am Wednesday 14 July 2010 schrieb Brian Davis:
I have a macro which gets called to create cuda and matlab mex enabled
libraries and apps. I call this macro **twice from within a single
directory** to create 2 libraries. Problem is that I desire to set
compiler defines -DWHATEVER=goop etc
14 matches
Mail list logo
