Re: [CMake] #1f/#endif trouble...

Am Sonntag 16 August 2009 23:27:54 schrieb ML: I have: #if TARGET_OS_MAC typedef unsigned char UInt8; typedef signed char SInt8; typedef unsigned short

[CMake] cmake from eclipse has error but cmake from shell works fine??!? help!

I have a relatively simple cmake file that has generated a great big Makefile (and associated CMake files) that compiles my project just fine when I invoke it from the bash shell, simply by typing 'make'. When I configure eclipse to do the same thing (simply calling make in the same directory)

Re: [CMake] #1f/#endif trouble...

On 8/16/09 2:27 PM, ML said: I am continuing my quest moving from XCode to CMake/Make This may be a Make specific question though. It would seem to me that #if TARGET_OS_MAC #endif is not getting executed in my code. I have: #if TARGET_OS_MAC typedef unsigned char

Re: [CMake] #1f/#endif trouble...

Hi Sean, It would seem to me that #if TARGET_OS_MAC #endif is not getting executed in my code. I have: #if TARGET_OS_MAC typedef unsigned char UInt8; typedef signed char

[CMake] Ensuring not building for 64-bit

Hi All, I am running into some issues with some Carbon stuff that is not avail under 64-bit, but is for 32-but. Items like: framework/CP_Types.h(304): error: identifier CIconHandle is undefined typedef CIconHandle OSColorIcon; // Mac

Re: [CMake] linking with .so w/ non-standard names

Hi Bill, I tried the same experiment with a boost .so and it worked. What's interesting is that I can link with thostmduserapi.so if I do it manually or just renamed it, and the application works, so it looks like the file is a valid object. gcc/c++ doesn't complain about a bad object

Re: [CMake] Ensuring not building for 64-bit

# if defined ((__APPLE__)) defined(__LP64__) __LP64__ // 64 bit headers/defines/typedefs here #else // 32 bit headers/defines/typedefs here #endif _ Mike Jackson mike.jack...@bluequartz.net BlueQuartz Software

Re: [CMake] Ensuring not building for 64-bit

On 8/17/09 7:41 AM, ML said: I am running into some issues with some Carbon stuff that is not avail under 64-bit, but is for 32-but. May I suggest you start by getting your stuff working in 32 bit first. With all the old Carbon stuff you use, 64 bit support will be more work. And as you're

Re: [CMake] linking with .so w/ non-standard names

Kenneth Chang wrote: Hi Bill, I tried the same experiment with a boost .so and it worked. What's interesting is that I can link with thostmduserapi.so if I do it manually or just renamed it, and the application works, so it looks like the file is a valid object. gcc/c++ doesn't complain

Re: [CMake] Ensuring not building for 64-bit

Hi Sean, I am running into some issues with some Carbon stuff that is not avail under 64-bit, but is for 32-but. May I suggest you start by getting your stuff working in 32 bit first. With all the old Carbon stuff you use, 64 bit support will be more work. And as you're apparently changing

Re: [CMake] Ensuring not building for 64-bit

The double __LP64__ is making sure it (__LP64__) is both DEFINED and TRUE. # if defined ((__APPLE__)) defined(__LP64__) __LP64__ typedef CIconHandle OSColorIcon; // Mac CIcon #else #endif _ Mike Jackson

Re: [CMake] Ensuring not building for 64-bit

Hi Mike, The double __LP64__ is making sure it (__LP64__) is both DEFINED and TRUE. # if defined ((__APPLE__)) defined(__LP64__) __LP64__ typedef CIconHandle OSColorIcon; // Mac CIcon #else To to help me fine tune a bit.. Wouldn't (__APPLE__) be automatically defined if I am compiling

Re: [CMake] Ensuring not building for 64-bit

On Aug 17, 2009, at 12:30 PM, ML wrote: Hi Mike, The double __LP64__ is making sure it (__LP64__) is both DEFINED and TRUE. # if defined ((__APPLE__)) defined(__LP64__) __LP64__ typedef CIconHandle OSColorIcon; // Mac CIcon #else To to help me fine tune a bit.. Wouldn't (__APPLE__)

Re: [CMake] Ensuring not building for 64-bit

On Aug 17, 2009, at 12:30 PM, ML wrote: Hi Mike, The double __LP64__ is making sure it (__LP64__) is both DEFINED and TRUE. # if defined ((__APPLE__)) defined(__LP64__) __LP64__ typedef CIconHandle OSColorIcon; // Mac CIcon #else To to help me fine tune a bit.. Wouldn't (__APPLE__)

Re: [CMake] linking with .so w/ non-standard names

Kenneth Chang wrote: thx, yes, it's 64-bit linux. So, Brad King is the person who is the expert in the elf linking in CMake, and he is on vacation right now. I did find this comment, which describes pretty much what is going on: From cmComputeLinkInformation.cxx:

Re: [CMake] Ensuring not building for 64-bit

On 17. Aug, 2009, at 18:40, Michael Jackson wrote: On Aug 17, 2009, at 12:30 PM, ML wrote: Hi Mike, The double __LP64__ is making sure it (__LP64__) is both DEFINED and TRUE. # if defined ((__APPLE__)) defined(__LP64__) __LP64__ typedef CIconHandle OSColorIcon; // Mac CIcon #else

Re: [CMake] Ensuring not building for 64-bit

On Aug 17, 2009, at 2:16 PM, Michael Wild wrote: On 17. Aug, 2009, at 18:40, Michael Jackson wrote: On Aug 17, 2009, at 12:30 PM, ML wrote: Hi Mike, The double __LP64__ is making sure it (__LP64__) is both DEFINED and TRUE. # if defined ((__APPLE__)) defined(__LP64__) __LP64__

[CMake] Qt stand alone and deployable bundle OS X application

Hi all, I am trying to make a stand alone bundle OS X application using CMake. My application is based on Qt4.5. I have been following the following wiki page (with QtTest example): http://www.cmake.org/Wiki/BuildingOSXApplications This bundle application works perfectly on a machine where

Re: [CMake] Qt stand alone and deployable bundle OS X application

Hi Arnaud, I am trying to make a stand alone bundle OS X application using CMake. My application is based on Qt4.5. I have been following the following wiki page (with QtTest example): http://www.cmake.org/Wiki/BuildingOSXApplications This bundle application works perfectly on a machine

[CMake] eclipse-cmake bug - more info

Here is the verbose output. remember, this only happens when I invoke make from eclipse. when I invoke make from the shell, everything is fine. thanks for any insight Build of configuration Linux GCC for project mdc make appmonitor VERBOSE=1

Re: [CMake] Qt stand alone and deployable bundle OS X application

The fixup bundle function _should_ be taking care of any dylib or framework that is linked to your application. If the function is NOT doing this then either we need better instructions, updated instructions or the function has been mis-used. I am betting a little bit of all of that. I use the

Re: [CMake] eclipse-cmake bug - more info

cd /home/Development/AMI_MDC_Dev_ Branch/Arm/MMP /home/cmake-2.6.4-Linux-i386/bin/cmake -E cmake_depends Unix Makefiles /home/Development/AMI_MDC_Dev_Branch/Arm/MMP /home/Development/AMI_MDC_Dev_Branch/Arm/MMP /home/Development/AMI_MDC_Dev_Branch/Arm/MMP