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:/_
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
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-g
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
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
bo
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
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 ot
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
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
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 Bl
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) w
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.
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 dep
20 matches
Mail list logo