[CMake] Problem using cmake with mingw

I'm trying to compile OIS with cmake I've managed to do this with a VS 2005 solution generated by cmake and it works fine but when i try to do it with a mingw makefile I get this error D:\ScatteredLands\Project\trunk\buildgccmingw32-make Scanning dependencies of target ois [ 0%] Building CXX

[CMake] Problem using cmake with mingw

I'm trying to compile OIS with cmake I've managed to do this with a VS 2005 solution generated by cmake and it works fine but when i try to do it with a mingw makefile I get this error D:\ScatteredLands\Project\trunk\buildgccmingw32-make Scanning dependencies of target ois [ 0%] Building CXX

[CMake] building from CVS fails on Linux

Hi! I get: % configure - CMake 2.5-20070219, Copyright (c) 2006 Kitware, Inc., Insight Consortium C compiler on this system is: cc C++ compiler on this system is: g++ Makefile processor on this system is: gmake g++ is GNU compiler g++ has STL in std::

[CMake] Progress report

Hi! Just a tiny, trvial thing... I have the problem that the progress report shows me something long 120% when finished. The relevant CMakeLists.txt is here: http://galinha.ucpel.tche.br/chicken/CMakeLists.txt This behaviour appears to exist on all platforms that I know of (Linux, Windows, OS

[CMake] Trouble with libraries on MacOS X

Hello, I'm using CMake 2.4.6 on a PowerPC iBook running MacOS X 10.4.8 and I found some issues with building both shared and static libraries and with linking to static libraries using CMake. I have attached a very simple example project to this e-mail that can be used to demonstrate the

RE: [CMake] Progress report

It can go above 100% if you are using an old version of CMake (2.4.3 maybe or older) or if you have multiple makes running at the same time. (not make -j that is OK, but make foo in one shell while you do make bar in another shell where foo and bar are in the same Makefile) This can also happen I

[CMake] Re: Trouble with libraries on MacOS X

Thomas Christian Chust wrote: I consider this seriously buggy behaviour. First of all I don't like it that the build system magically wipes out one of the library targets I ordered it to create. See SET_TARGET_PROPERTIES in the docs. When a library is built CMake by default generates code to

[CMake] Correct way to build for 64 bit?

[snip] 2. For the windows cl, a try compile is done to figure out which cl you are using. For the IDE, there is a separate generator for the 64 bit tool because you have to use a different tool. So, you either run vcvars64.bat then cmake for nmake, or you pick the 64 bit IDE build. [...]

Re: [CMake] Re: Trouble with libraries on MacOS X

Brandon J. Van Every wrote: Thomas Christian Chust wrote: I consider this seriously buggy behaviour. First of all I don't like it that the build system magically wipes out one of the library targets I ordered it to create. [...] This can be prevented by setting the CLEAN_DIRECT_OUTPUT

Re: [CMake] Correct way to build for 64 bit?

Stephane Rouleau (Consultant) wrote: [snip] 2. For the windows cl, a try compile is done to figure out which cl you are using. For the IDE, there is a separate generator for the 64 bit tool because you have to use a different tool. So, you either run vcvars64.bat then cmake for nmake, or you

RE: [CMake] Correct way to build for 64 bit?

That's not what I wanted to read of course. :) Has there been any thoughts given to adding support for this? When building through a vcproj you can cross-compile win32/x64 on 32 and 64 bits Windows, provided the proper compiler tools have been installed. Anyway, it's not the end of the world.

Re: [CMake] Correct way to build for 64 bit?

Stephane Rouleau (Consultant) wrote: That's not what I wanted to read of course. :) Has there been any thoughts given to adding support for this? When building through a vcproj you can cross-compile win32/x64 on 32 and 64 bits Windows, provided the proper compiler tools have been installed.