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

2009-08-17 Thread Philip Lowman
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 /home/Development/AMI_MDC_Dev_Branch/Ar

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

2009-08-17 Thread Mike Jackson
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 fi

[CMake] eclipse-cmake bug - more info

2009-08-17 Thread Steve Mathers
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 /home/cmake-2.6.4-Linux-i386/bin/cmak

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

2009-08-17 Thread ML
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 wher

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

2009-08-17 Thread Arnaud GELAS
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 Qt

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

2009-08-17 Thread Michael Jackson
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__

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

2009-08-17 Thread Michael Wild
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 #els

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

2009-08-17 Thread Bill Hoffman
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

2009-08-17 Thread Michael Jackson
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

2009-08-17 Thread Michael Jackson
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

2009-08-17 Thread ML
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 compil

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

2009-08-17 Thread Michael Jackson
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 mike.jack

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

2009-08-17 Thread ML
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] linking with .so w/ non-standard names

2009-08-17 Thread Bill Hoffman
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 abo

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

2009-08-17 Thread Sean McBride
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] Ensuring not building for 64-bit

2009-08-17 Thread Michael Jackson
# 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] linking with .so w/ non-standard names

2009-08-17 Thread Kenneth Chang
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 eithe

[CMake] Ensuring not building for 64-bit

2009-08-17 Thread ML
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] #1f/#endif trouble...

2009-08-17 Thread ML
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 S

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

2009-08-17 Thread Sean McBride
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

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

2009-08-17 Thread Steve Mathers
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)