date:20150106

[CMake] Unable to create project files with Visual Studio 2010 on Windows 7

2015-01-06 Thread David . Karr

I have just started using a new Windows 7 host with Visual Studio 2010 
Professional. When I call CMake to generate my project files, I get the 
following output in CMakeError.log:

==
Determining if the C compiler works failed with the following output:
Change Dir: C://__/CMakeFiles/CMakeTmp

Run Build Command:C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe 
cmTryCompileExec.vcxproj /p:Configuration=Debug
Microsoft (R) Build Engine version 4.0.30319.17929
[Microsoft .NET Framework, version 4.0.30319.18034]
Copyright (C) Microsoft Corporation. All rights reserved.

Build started 1/6/2015 6:15:19 PM.
Project 
"C:\\__\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj"
 on node 1 (default targets).
InitializeBuildStatus:
  Creating "cmTryCompileExec.dir\Debug\cmTryCompileExec.unsuccessfulbuild" 
because "AlwaysCreate" was specified.
ClCompile:
  C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\CL.exe /c /Zi 
/nologo /W3 /WX- /Od /Ob0 /Oy- /D WIN32 /D _WINDOWS /D _DEBUG /D 
"CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise /Zc:wchar_t 
/Zc:forScope /Fo"cmTryCompileExec.dir\Debug\\" 
/Fd"C://__/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec.pdb"
 /Gd /TC /analyze- /errorReport:queue testCCompiler.c  /Zm1000
TRACKER : error TRK0002: Failed to execute command: ""C:\Program Files 
(x86)\Microsoft Visual Studio 10.0\VC\bin\CL.exe" 
@C:\Users\\AppData\Local\Temp\tmp9db9bf329c554cb8be447cdb72535c4e.rsp".
 The requested operation requires elevation. 
[C:\\__\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj]


Done Building Project 
"C:\\__\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj"
 (default targets) -- FAILED.

Build FAILED.

"C:\\__\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj"
 (default target) (1) ->
(ClCompile target) ->
  TRACKER : error TRK0002: Failed to execute command: ""C:\Program Files 
(x86)\Microsoft Visual Studio 10.0\VC\bin\CL.exe" 
@C:\Users\\AppData\Local\Temp\tmp9db9bf329c554cb8be447cdb72535c4e.rsp".
 The requested operation requires elevation. 
[C:\\__\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj]

0 Warning(s)
1 Error(s)

Time Elapsed 00:00:00.10
==

The only thing I've changed in the output text is I replaced some user-specific 
directory names with underscores or "".

This project previously built just fine on Windows XP. Moreover, my coworker, 
who as far as we can tell set up his Windows 7 host the same way I did (modulo 
some things that shouldn't matter, such as I have a copy of Emacs and he 
doesn't), is able to build the same project files without error.

It may be noteworthy that after this failure, the file 
CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj does not exist, and there are no 
files whatsoever in CMakeFiles\CMakeTmp\cmTryCompileExec.dir\Debug.

I have been trying all kinds of suggestions I have found by looking up the 
message "The requested operation requires elevation." I have tried setting 
ownership of the directories (it turns out I owned them all along), I have 
tried setting access rights (already set to full access), I tried turning off 
UAC, and I even tried repairing the installation of Visual Studio 2010. None of 
it made any difference.

I've found some Web sites where some people have complained of problems when 
they had installed Visual Studio 2012 and tried to use Visual Studio 2010. But 
Visual Studio 2010 is the only version that has been installed on this host.

This has had me dead in the water for at least a day, unable to make any 
progress on my actual project. Does anyone have any ideas about where to even 
begin to look for solutions I haven't already tried?

David



-- 

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

2015-01-06 Thread James Bigler

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_ 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 
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 > > 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> > 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>
>> __;$<$:-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
>>
>>

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

2015-01-06 Thread Irwin Zaid

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
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
Zaidmailto: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
"$<$:-Xcompiler>__;$<$:-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

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

2015-01-06 Thread James Bigler

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 
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
  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>;$<$:-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
 $<$:-Xcompiler>;$<$:-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/b

Re: [CMake] Get the BINARY_DIR for a target?

2015-01-06 Thread Braden McDaniel

On Tue, 2015-01-06 at 12:34 -0500, Braden McDaniel wrote:
> Are there any properties on a target that I can query to get whatever
> was the CMAKE_CURRENT_BINARY_DIR when the target was defined?
> 
> I'm aware of the LOCATION property; however, its generator-specific
> nature makes teasing the non-generator-specific part out of it rather
> challenging (without some other information about the target
> definition's location in the source tree, which is specifically what I'm
> trying to avoid).  FWIW, I'm writing a function that takes a list of
> targets as input.

It looks like I can add my own arbitrary property for this.  So, my
current solution is to wrap add_library with my own function that calls
add_library and then sets MY_SPECIAL_PROPERTY on the target to the
current value of CMAKE_CURRENT_BINARY_DIR.

Later, I get the value of MY_SPECIAL_PROPERTY inside the function I
described in my previous message.

If someone knows of a better way, do tell.

-- 
Braden McDaniel 

-- 

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

2015-01-06 Thread Irwin Zaid

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   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>;$<$:-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 
$<$:-Xcompiler>;$<$:-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 
$<$:-Xcompiler>;$<$:-fPIC>

James Bigler wrote:

I meant putting messages into FindCUDA.cmake itself.

Only certain fl

[CMake] add_subdirectory cache configuration via cmake script

2015-01-06 Thread Dario Oliveri

How can I prevent variables cache pollution in CMAKE?

My real problem is the following:

I have library A and library B, both libraries have some cmake variable
used to configure there and there and that's ok, but what
when variables are semantically duplicated?

Library A depends on Library B

both libraries provide "CompileForLinux" cache variable, I want be able to
just compile library A and check the checkbox for "CompileForLinux" just
once.

This example is the minimum of course, but it would be nice if there's
someway to wrap variables of dependencies so that I can compile a library
with less chance of "human error prone" misconfiguration and to provide
final user of library A only the few real needed options/variables.

Libray A is actually including library B using "add_subdirectory"

So assume the following boolean cache variables:

LIBA_STATIC
LIBA_SHARED
LIBA_OBJECT
LIBB_STATIC
LIBB_SHARED
LIBB_OBJECT
LIBA_EXCLUDE_MODULE1
LIBB_EXCLUDE_MODULE1
COMPILE_FOR_LINUX   #from libA
COMPILE_FOR_LINUX   #from libB

It would be nice letting LIB A to hide unecessary staff that can be
configured by the cmake script without the user have to know it.

Final expected list to be showed in Cmake-gui


LIBA_STATIC  # configure libB accordingly
LIBA_SHARED
LIBA_OBJECT
LIBA_EXCLUDE_MODULE1
LIBB_EXCLUDE_MODULE1   #not hided by libA because necessary for final
configuration
COMPILE_FOR_LINUX   #from libA

I Hope you see how that can be tremendously usefulll especially in
opensource cross-platform projects with many dependencies
-- 

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

2015-01-06 Thread Irwin Zaid

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 
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.



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 
$<$:-Xcompiler>;$<$:-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 
$<$:-Xcompiler>;$<$:-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

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

2015-01-06 Thread James Bigler




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>;$<$:-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
>  $<$:-Xcompiler>;$<$:-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
>  $<$:-Xcompiler>;$<$:-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 spe

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

2015-01-06 Thread Irwin Zaid

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 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 
$<$:-Xcompiler>;$<$:-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 
$<$:-Xcompiler>;$<$:-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 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
mailto:irwin.z...@physics.ox.ac.uk>
>> wrote:

[CMake] Get the BINARY_DIR for a target?

2015-01-06 Thread Braden McDaniel

Are there any properties on a target that I can query to get whatever
was the CMAKE_CURRENT_BINARY_DIR when the target was defined?

I'm aware of the LOCATION property; however, its generator-specific
nature makes teasing the non-generator-specific part out of it rather
challenging (without some other information about the target
definition's location in the source tree, which is specifically what I'm
trying to avoid).  FWIW, I'm writing a function that takes a list of
targets as input.

-- 
Braden McDaniel 

-- 

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

2015-01-06 Thread James Bigler

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 
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 > > 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 $<$:${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 $<$:-__Xcompiler>
>> $<$:${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

2015-01-06 Thread Irwin Zaid


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 
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 $<$:${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 $<$:-__Xcompiler>
$<$:${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

2015-01-06 Thread James Bigler

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_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 $<$:${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 $<$:-Xcompiler>
> $<$:${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

2015-01-06 Thread Irwin Zaid


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 $<$:${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 $<$:-Xcompiler> $<$:${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 
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
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 i

Re: [CMake] Bug in SLN generation

2015-01-06 Thread Scott Aron Bloom

The other problem with the script technique,  is most of my devs use cmake 
inside visual Studio..


--Scott


 Original message 
From: David Cole 
Date:01/06/2015 07:35 (GMT-08:00)
To: Petr Kmoch 
Cc: Scott Aron Bloom , cmake@cmake.org
Subject: Re: [CMake] Bug in SLN generation

No, with the wrapper script technique, you'd have to train all your
developers to run the wrapper script whenever any "CMake stuff"
changes...


On Tue, Jan 6, 2015 at 8:39 AM, Petr Kmoch  wrote:
> On Tue, Jan 6, 2015 at 2:29 PM, David Cole  wrote:
>>
>> Two ways to do this occur to me:
>>
>> (1) wrap cmake with a two-line script that your project developers use:
>> @call cmake -G "Visual Studio 12 2013"
>> @call post-cmake.cmd
>
>
> Would this work with re-runs triggered by CMake itself (e.g. by ZERO_CHECK)?
>
>>
>>
>> (2) do a file(WRITE ...) unconditionally somewhere in your
>> CMakeLists.txt file, and then introduce a custom command that depends
>> on that file, and a custom target for that command to live in, and
>> then make all your other targets depend on that one. That way, the
>> first thing that happens in a build is your "post-CMake" step. (this
>> one will be a weird interactive experience in Visual Studio, though,
>> if your custom command modifies the sln/vcxproj files...)
>>
>> Perhaps neither is "ideal," but either technique should be able to
>> help you until an ideal solution can be implemented.
>>
>>
>> HTH,
>> David C.
>>
>>
>> On Tue, Jan 6, 2015 at 2:50 AM, Petr Kmoch  wrote:
>> > Hi Scott.
>> >
>> > To file a bug, use the Mantis tracker at http://public.kitware.com/Bug/
>> >
>> > As for running custom processing post-generation, there is no way hook
>> > this,
>> > and a request for it was explicitly declined:
>> > http://public.kitware.com/Bug/view.php?id=13020
>> >
>> > Petr
>> >
>> > On Mon, Jan 5, 2015 at 8:53 PM, Scott Aron Bloom
>> > 
>> > wrote:
>> >>
>> >> I have found a bug in SLN generation when the property USE_FOLDERS  is
>> >> set
>> >> to on.
>> >>
>> >>
>> >> The order of the folders, and vcprojects added to the folders is not
>> >> sorted.  It is sorted correctly if USE_FOLDERS is not set.
>> >>
>> >>
>> >>
>> >> I have two questions, first, what is the appropriate mechanism for
>> >> filing
>> >> a bug? I will create a trivial testcase to show the issue.
>> >>
>> >>
>> >>
>> >> Second, in the meantime I have a way to fix the sln file, as a post
>> >> process after its generated.  What type of rule could I add to the
>> >> CMakeLists.txt file to run after the sln has been generated/updated by
>> >> cmake?
>> >>
>> >> Scott
>
>
-- 

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] Bug in SLN generation

2015-01-06 Thread Scott Aron Bloom

I filed a bug yesterday,  and may take a look at the source code and look into 
a coding thr patch this week.

I did find the previous bug as well once I Google the right keywords...


--Scott


 Original message 
From: Petr Kmoch 
Date:01/05/2015 23:50 (GMT-08:00)
To: Scott Aron Bloom 
Cc: cmake@cmake.org
Subject: Re: [CMake] Bug in SLN generation

Hi Scott.

To file a bug, use the Mantis tracker at http://public.kitware.com/Bug/

As for running custom processing post-generation, there is no way hook this, 
and a request for it was explicitly declined: 
http://public.kitware.com/Bug/view.php?id=13020

Petr

On Mon, Jan 5, 2015 at 8:53 PM, Scott Aron Bloom 
mailto:scott.bl...@onshorecs.com>> wrote:
I have found a bug in SLN generation when the property USE_FOLDERS  is set to 
on.

The order of the folders, and vcprojects added to the folders is not sorted.  
It is sorted correctly if USE_FOLDERS is not set.

I have two questions, first, what is the appropriate mechanism for filing a 
bug? I will create a trivial testcase to show the issue.

Second, in the meantime I have a way to fix the sln file, as a post process 
after its generated.  What type of rule could I add to the CMakeLists.txt file 
to run after the sln has been generated/updated by cmake?

Scott

--

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] Bug in SLN generation

2015-01-06 Thread David Cole via CMake

No, with the wrapper script technique, you'd have to train all your
developers to run the wrapper script whenever any "CMake stuff"
changes...


On Tue, Jan 6, 2015 at 8:39 AM, Petr Kmoch  wrote:
> On Tue, Jan 6, 2015 at 2:29 PM, David Cole  wrote:
>>
>> Two ways to do this occur to me:
>>
>> (1) wrap cmake with a two-line script that your project developers use:
>> @call cmake -G "Visual Studio 12 2013"
>> @call post-cmake.cmd
>
>
> Would this work with re-runs triggered by CMake itself (e.g. by ZERO_CHECK)?
>
>>
>>
>> (2) do a file(WRITE ...) unconditionally somewhere in your
>> CMakeLists.txt file, and then introduce a custom command that depends
>> on that file, and a custom target for that command to live in, and
>> then make all your other targets depend on that one. That way, the
>> first thing that happens in a build is your "post-CMake" step. (this
>> one will be a weird interactive experience in Visual Studio, though,
>> if your custom command modifies the sln/vcxproj files...)
>>
>> Perhaps neither is "ideal," but either technique should be able to
>> help you until an ideal solution can be implemented.
>>
>>
>> HTH,
>> David C.
>>
>>
>> On Tue, Jan 6, 2015 at 2:50 AM, Petr Kmoch  wrote:
>> > Hi Scott.
>> >
>> > To file a bug, use the Mantis tracker at http://public.kitware.com/Bug/
>> >
>> > As for running custom processing post-generation, there is no way hook
>> > this,
>> > and a request for it was explicitly declined:
>> > http://public.kitware.com/Bug/view.php?id=13020
>> >
>> > Petr
>> >
>> > On Mon, Jan 5, 2015 at 8:53 PM, Scott Aron Bloom
>> > 
>> > wrote:
>> >>
>> >> I have found a bug in SLN generation when the property USE_FOLDERS  is
>> >> set
>> >> to on.
>> >>
>> >>
>> >> The order of the folders, and vcprojects added to the folders is not
>> >> sorted.  It is sorted correctly if USE_FOLDERS is not set.
>> >>
>> >>
>> >>
>> >> I have two questions, first, what is the appropriate mechanism for
>> >> filing
>> >> a bug? I will create a trivial testcase to show the issue.
>> >>
>> >>
>> >>
>> >> Second, in the meantime I have a way to fix the sln file, as a post
>> >> process after its generated.  What type of rule could I add to the
>> >> CMakeLists.txt file to run after the sln has been generated/updated by
>> >> cmake?
>> >>
>> >> Scott
>
>
-- 

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] Bug in SLN generation

2015-01-06 Thread Petr Kmoch

On Tue, Jan 6, 2015 at 2:29 PM, David Cole  wrote:

> Two ways to do this occur to me:
>
> (1) wrap cmake with a two-line script that your project developers use:
> @call cmake -G "Visual Studio 12 2013"
> @call post-cmake.cmd
>

Would this work with re-runs triggered by CMake itself (e.g. by ZERO_CHECK)?


>
> (2) do a file(WRITE ...) unconditionally somewhere in your
> CMakeLists.txt file, and then introduce a custom command that depends
> on that file, and a custom target for that command to live in, and
> then make all your other targets depend on that one. That way, the
> first thing that happens in a build is your "post-CMake" step. (this
> one will be a weird interactive experience in Visual Studio, though,
> if your custom command modifies the sln/vcxproj files...)
>
> Perhaps neither is "ideal," but either technique should be able to
> help you until an ideal solution can be implemented.
>
>
> HTH,
> David C.
>
>
> On Tue, Jan 6, 2015 at 2:50 AM, Petr Kmoch  wrote:
> > Hi Scott.
> >
> > To file a bug, use the Mantis tracker at http://public.kitware.com/Bug/
> >
> > As for running custom processing post-generation, there is no way hook
> this,
> > and a request for it was explicitly declined:
> > http://public.kitware.com/Bug/view.php?id=13020
> >
> > Petr
> >
> > On Mon, Jan 5, 2015 at 8:53 PM, Scott Aron Bloom <
> scott.bl...@onshorecs.com>
> > wrote:
> >>
> >> I have found a bug in SLN generation when the property USE_FOLDERS  is
> set
> >> to on.
> >>
> >>
> >> The order of the folders, and vcprojects added to the folders is not
> >> sorted.  It is sorted correctly if USE_FOLDERS is not set.
> >>
> >>
> >>
> >> I have two questions, first, what is the appropriate mechanism for
> filing
> >> a bug? I will create a trivial testcase to show the issue.
> >>
> >>
> >>
> >> Second, in the meantime I have a way to fix the sln file, as a post
> >> process after its generated.  What type of rule could I add to the
> >> CMakeLists.txt file to run after the sln has been generated/updated by
> >> cmake?
> >>
> >> Scott
>
-- 

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] Bug in SLN generation

2015-01-06 Thread David Cole via CMake

Two ways to do this occur to me:

(1) wrap cmake with a two-line script that your project developers use:
@call cmake -G "Visual Studio 12 2013"
@call post-cmake.cmd

(2) do a file(WRITE ...) unconditionally somewhere in your
CMakeLists.txt file, and then introduce a custom command that depends
on that file, and a custom target for that command to live in, and
then make all your other targets depend on that one. That way, the
first thing that happens in a build is your "post-CMake" step. (this
one will be a weird interactive experience in Visual Studio, though,
if your custom command modifies the sln/vcxproj files...)

Perhaps neither is "ideal," but either technique should be able to
help you until an ideal solution can be implemented.


HTH,
David C.


On Tue, Jan 6, 2015 at 2:50 AM, Petr Kmoch  wrote:
> Hi Scott.
>
> To file a bug, use the Mantis tracker at http://public.kitware.com/Bug/
>
> As for running custom processing post-generation, there is no way hook this,
> and a request for it was explicitly declined:
> http://public.kitware.com/Bug/view.php?id=13020
>
> Petr
>
> On Mon, Jan 5, 2015 at 8:53 PM, Scott Aron Bloom 
> wrote:
>>
>> I have found a bug in SLN generation when the property USE_FOLDERS  is set
>> to on.
>>
>>
>> The order of the folders, and vcprojects added to the folders is not
>> sorted.  It is sorted correctly if USE_FOLDERS is not set.
>>
>>
>>
>> I have two questions, first, what is the appropriate mechanism for filing
>> a bug? I will create a trivial testcase to show the issue.
>>
>>
>>
>> Second, in the meantime I have a way to fix the sln file, as a post
>> process after its generated.  What type of rule could I add to the
>> CMakeLists.txt file to run after the sln has been generated/updated by
>> cmake?
>>
>> Scott
>>
>>
>> --
>>
>> 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
-- 

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

[CMake] Unable to create project files with Visual Studio 2010 on Windows 7

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

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

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

Re: [CMake] Get the BINARY_DIR for a target?

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

[CMake] add_subdirectory cache configuration via cmake script

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

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

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

[CMake] Get the BINARY_DIR for a target?

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

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

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

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

Re: [CMake] Bug in SLN generation

Re: [CMake] Bug in SLN generation

Re: [CMake] Bug in SLN generation

Re: [CMake] Bug in SLN generation

Re: [CMake] Bug in SLN generation

20 matches

Site Navigation

Mail list logo

Footer information