On Wed, Sep 19, 2012 at 1:48 PM, Bogdan Cristea wrote:
> On Wednesday 19 September 2012 08:56:02 you wrote:
> > Premium and Express are two very different beasts.
>
> Indeed, just learned that: I have used cmake 2.8.8 and it detects VS 2012
> ultimate, while cmake 2.8.9 does not detect VS 2012 Ex
On Wednesday 19 September 2012 08:56:02 you wrote:
> Premium and Express are two very different beasts.
Indeed, just learned that: I have used cmake 2.8.8 and it detects VS 2012
ultimate, while cmake 2.8.9 does not detect VS 2012 Express for Win8.
Are there any plans to support VS Express 2012 ?
Andreas Naumann wrote:
> Hi,
>
> it is an interesting problem. If you tell the gcc to use the math library,
> it works. The interesting thing is the way of testing.
>
> The cmake macro simply declares a function foo with the signature
> char foo();
> and call this one without arguments. If yo
Hi,
it is an interesting problem. If you tell the gcc to use the math
library, it works. The interesting thing is the way of testing.
The cmake macro simply declares a function foo with the signature
char foo();
and call this one without arguments. If you tell cmake to link against
the ma
Jack Stalnaker wrote:
> Hi,
>
> I'm having trouble with check_function_exists() when it comes to built-in
> functions in gcc. If I create just a simple C++ file with a call to sqrt()
> or pow() and have a CMakeLists.txt with the following lines,
>
> include (CheckFunctionExists)
> check_function_
Perhaps use check_c_source_compiles?
## Check for specific apple platforms
macro(check_apple_platform)
if(APPLE)
include(CheckCSourceCompiles)
check_c_source_compiles("
#include \"TargetConditionals.h\"
int main(int argc, char *argv[]) {
#if !TARGET_OS_MAC
-1
Hi,
I'm having trouble with check_function_exists() when it comes to built-in
functions in gcc. If I create just a simple C++ file with a call to sqrt()
or pow() and have a CMakeLists.txt with the following lines,
include (CheckFunctionExists)
check_function_exists(sqrt HAVE_SQRT)
cmake fails to
Stupid, stupid me. Yes it works, I just ran GDB with "start" instead of
"run".
Thanks for your help Nils.
Chris
On 2012/09/19 04:56 PM, Nils Gladitz wrote:
"cmake -DCMAKE_BUILD_TYPE=Debug" should be enough to get gdb
debuggable binaries.
Is the process which you intend to debug running when y
"cmake -DCMAKE_BUILD_TYPE=Debug" should be enough to get gdb debuggable
binaries.
Is the process which you intend to debug running when you ask gdb for a
backtrace?
You will only be able to get a backtrace if the process has been started
and has not yet exited.
e.g.:
gdb ./mybin
break main
run
Hi,
I'm trying to debug my program using GDB. I've done the following:
-DCMAKE_BUILD_TYPE=Debug
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fPIC -g")
SET(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -g")
But whenever I run GDB and do a backtrace, I get a message: "No Stack".
I've done a Google
Hello,
is it possible to use different libraries for sub projects?
For example if a sub project needs dynamic linked boost 1.48 library and a
other sub project needs static linked boost 1.51 library.
The same could be for Qt projects too.
Thanks in advance
Best Regards
--
Powered by www.kitwar
On 19.09.2012 10:19, Wouter van Kleunen wrote:
Peter,
yes I figured it would be something like that, compilations per seconds.
But did the ninja developers remove this option ?
No, I've added it ;), but the official ninja binary is not a 1.0 version,
it's two months old.
I tried the ninja
Peter,
yes I figured it would be something like that, compilations per seconds.
But did the ninja developers remove this option ?
I tried the ninja version you uploaded to github and this also works fine.
Wouter
> On 19.09.2012 09:48, Wouter van Kleunen wrote:
>>
>> Peter,
>>
>> I guess removi
On 19.09.2012 09:48, Wouter van Kleunen wrote:
Peter,
I guess removing just the build directory also seems to work.
I agree with your objections of the location the user file, the source
directory should stay clean. An inattentive moment and you have the file
in your version control.
Anyway,
Peter,
I guess removing just the build directory also seems to work.
I agree with your objections of the location the user file, the source
directory should stay clean. An inattentive moment and you have the file
in your version control.
Anyway, it seems to build now using an older version of n
Yes, starting from scratch helps in most cases. But with cmake
we are used to simply clean the build dir, which doesn't help here.
It is a problem that creator's .user file is stored beside
the CMakeLists.txt: you can't check it in because of absolute paths,
a clean of the repository removes it,
16 matches
Mail list logo