CMake build system for Cthugha *looking for testers*
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Re: CMake build system for Cthugha *looking for testers*
It's hard-coded to look in the ../samples directory (relative from the dependencies directory) as well.
So if you don't have this directory layout, it won't work:
Ogre ->
dependencies
Samples
Notice that dependencies and Samples are on the same level.
So if you don't have this directory layout, it won't work:
Ogre ->
dependencies
Samples
Notice that dependencies and Samples are on the same level.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: CMake build system for Cthugha *looking for testers*
Where did you extract the dependencies? Originally you were supposed to extract them directly into the Ogre source folder, that would take care of everything. Otherwise, you need to set OGRE_DEPENDENCIES_DIR to the location of the Dependencies directory, i. e. let's say you extracted the dependencies to C:\OgreDependencies, then you'd have the following dir structure:
C:\OgreDependencies\
+-- Dependencies\
+-- Samples\
You would have to set OGRE_DEPENDENCIES_DIR = C:/OgreDependencies/Dependencies
C:\OgreDependencies\
+-- Dependencies\
+-- Samples\
You would have to set OGRE_DEPENDENCIES_DIR = C:/OgreDependencies/Dependencies
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Re: CMake build system for Cthugha *looking for testers*
That's highly un-intuitive.CABAListic wrote:You would have to set OGRE_DEPENDENCIES_DIR = C:/OgreDependencies/Dependencies
It should be C:/OgreDependencies, not C:/OgreDependencies/dependencies.
Because the dependencies are made up off two directories: dependencies and Samples.
I am right.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: CMake build system for Cthugha *looking for testers*
The Samples directory will vanish, because it has lost its function. Therefore, ultimately my approach is correct
-
- Halfling
- Posts: 77
- Joined: Thu Jan 08, 2009 2:03 am
- x 1
Re: CMake build system for Cthugha *looking for testers*
Okay, if I delete the Dependencies folder from the SVN folder and correct as above, the Dependencies appear to work, but I get a new error asking for the file (OgreInstallDependencies.cmakeCABAListic wrote: You would have to set OGRE_DEPENDENCIES_DIR = C:/OgreDependencies/Dependencies
) that was in the Dependencies folder.
So, what must I do to fix this?
Code: Select all
Configuring OGRE 1.7.0
CMake Error at CMake/Dependencies.cmake:53 (include):
include could not find load file:
H:/Ogre SVN/Dependencies/OgreInstallDependencies.cmake
Call Stack (most recent call first):
CMakeLists.txt:99 (include)
Looking for ZLIB...
Found ZLIB: optimized;H:/OgreDependencies_VC9_Eihort_20080203/Dependencies/lib/release/zlib.lib;debug;H:/OgreDependencies_VC9_Eihort_20080203/Dependencies/lib/debug/zlibd.lib
Looking for ZZip...
Found ZZip: optimized;H:/OgreDependencies_VC9_Eihort_20080203/Dependencies/lib/release/zziplib.lib;debug;H:/OgreDependencies_VC9_Eihort_20080203/Dependencies/lib/debug/zziplibd.lib
Looking for FreeImage...
Found FreeImage: optimized;H:/OgreDependencies_VC9_Eihort_20080203/Dependencies/lib/release/FreeImage.lib;debug;H:/OgreDependencies_VC9_Eihort_20080203/Dependencies/lib/debug/FreeImaged.lib
Looking for FREETYPE...
Found FREETYPE: optimized;H:/OgreDependencies_VC9_Eihort_20080203/Dependencies/lib/release/freetype235.lib;debug;H:/OgreDependencies_VC9_Eihort_20080203/Dependencies/lib/debug/freetype235_D.lib
Looking for DirectX...
DirectX_PREFIX_PATH changed.
Found DirectX: H:/Microsoft DirectX SDK (August 2009)/Lib/x86/d3d9.lib
DX lib dir: H:/Microsoft DirectX SDK (August 2009)/Lib/x86
Looking for POCO...
Could not locate POCO
Looking for TBB...
Could not locate TBB
Looking for CEGUI...
Found CEGUI: optimized;H:/OgreDependencies_VC9_Eihort_20080203/Dependencies/lib/release/CEGUIBase.lib;debug;H:/OgreDependencies_VC9_Eihort_20080203/Dependencies/lib/debug/CEGUIBase_d.lib
Looking for OIS...
Found OIS: optimized;H:/OgreDependencies_VC9_Eihort_20080203/Dependencies/lib/release/OIS.lib;debug;H:/OgreDependencies_VC9_Eihort_20080203/Dependencies/lib/debug/OIS_d.lib
Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
Looking for CppUnit...
Could not locate CppUnit
-----------------------------------------------------------------------------
-- The following external packages were located on your system.
-- This installation will have the extra features provided by these packages.
+ zlib
+ zziplib
+ freeimage
+ freetype
+ OpenGL
+ OpenGL ES
+ DirectX
+ cg
+ boost
+ boost-thread
+ boost-date_time
+ CEGUI
+ OIS
-----------------------------------------------------------------------------
-- The following OPTIONAL packages could NOT be located on your system.
-- Consider installing them to enable more features from this software.
+ POCO: POCO framework <http://pocoproject.org/>
+ tbb: Threading Building Blocks <http://www.threadingbuildingblocks.org/>
+ Doxygen: Tool for building API documentation <http://doxygen.org>
+ CppUnit: Library for performing unit tests <http://cppunit.sourceforge.net>
-----------------------------------------------------------------------------
----------------------------------------------------------------------------
FEATURE SUMMARY
----------------------------------------------------------------------------
Building components:
+ Paging
+ Property
+ Terrain
Building plugins:
+ BSP scene manager
+ Cg program manager
+ Octree scene manager
+ Portal connected zone scene manager
+ Particle FX
Building rendersystems:
+ Direct3D 9
+ Direct3D 10
+ OpenGL
Building executables:
+ Samples
+ Tools
Building core features:
+ DDS image codec
+ FreeImage codec
+ ZIP archives
Build type: dynamic
Threading support: background (boost)
Use double precision: disabled
Allocator type: nedmalloc
STL containers use allocator: enabled
Strings use allocator: disabled
Memory tracker (debug): disabled
Memory tracker (release): disabled
Use new script compilers: enabled
Use Boost: enabled
----------------------------------------------------------------------------
Configuring incomplete, errors occurred!
The Key to Magic -- Book One: ORPHAN
An epic fantasy by H. Jonas Rhynedahll available on Kindle.
The Key to Magic
An epic fantasy by H. Jonas Rhynedahll available on Kindle.
The Key to Magic
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: CMake build system for Cthugha *looking for testers*
Ah yes, you need to copy that one to your Dependencies folder. As I said, ultimately the dependencies themselves should include that particular file...
-
- Halfling
- Posts: 77
- Joined: Thu Jan 08, 2009 2:03 am
- x 1
Re: CMake build system for Cthugha *looking for testers*
Okay, I copied the OgreInstallDependencies.cmake to my OGRE_DEPENDENCIES_DIR and just in case to the Dependencies folder below that.CABAListic wrote:Ah yes, you need to copy that one to your Dependencies folder. As I said, ultimately the dependencies themselves should include that particular file...
I still get the same error. The error specifies the SVN directory Dependencies folder.?
Code: Select all
Configuring OGRE 1.7.0
CMake Error at CMake/Dependencies.cmake:53 (include):
include could not find load file:
H:/Ogre SVN/Dependencies/OgreInstallDependencies.cmake
Call Stack (most recent call first):
CMakeLists.txt:99 (include)
The Key to Magic -- Book One: ORPHAN
An epic fantasy by H. Jonas Rhynedahll available on Kindle.
The Key to Magic
An epic fantasy by H. Jonas Rhynedahll available on Kindle.
The Key to Magic
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Re: CMake build system for Cthugha *looking for testers*
You probably forgot to delete CMakeCache.txt before re-configuring ?
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- Halfling
- Posts: 77
- Joined: Thu Jan 08, 2009 2:03 am
- x 1
Re: CMake build system for Cthugha *looking for testers*
Bingo!jacmoe wrote:You probably forgot to delete CMakeCache.txt before re-configuring ?
Works now!
The Key to Magic -- Book One: ORPHAN
An epic fantasy by H. Jonas Rhynedahll available on Kindle.
The Key to Magic
An epic fantasy by H. Jonas Rhynedahll available on Kindle.
The Key to Magic
-
- Ogre Magi
- Posts: 1120
- Joined: Wed Nov 15, 2006 7:41 pm
- Location: Finland
- x 5
Re: CMake build system for Cthugha *looking for testers*
Have the Ogre3D developers tested the static build themselves?
I did a dynamic build yesterday and getting an application up and running actually happened - with the static build I first tried to use it didn't happen yet... I just hit problem after problem and eventually decided I will have to try the dynamic build and see if that works.
In fact that isn't perfect either, as there is a crash on exit, and plenty of leaked memory reports even though the application is very very simple, it is just getting Ogre::Root and a Ogre::RenderWindow up and then runs a renderOneFrame and messagepump loop until the window is closed by the user. But a positive thing is the cmake scripts seem to work much better for the dynamic build and when using it with an application.
So yeah, I am interesting in whether the Ogre3D developers have themselves gotten the static version working, and have they created an application which works with it? It would be very helpful if there was an example script for an application when using a static build of Ogre3D. I will promise not to give up just yet with it, I will keep working and learning about cmake so I could fix the errors by myself if possible, but it would be helpful to know if someone knows for a fact it works like intended with an application.
I am talking of doing it all on Linux - on Debian 5 specifically.
I did a dynamic build yesterday and getting an application up and running actually happened - with the static build I first tried to use it didn't happen yet... I just hit problem after problem and eventually decided I will have to try the dynamic build and see if that works.
In fact that isn't perfect either, as there is a crash on exit, and plenty of leaked memory reports even though the application is very very simple, it is just getting Ogre::Root and a Ogre::RenderWindow up and then runs a renderOneFrame and messagepump loop until the window is closed by the user. But a positive thing is the cmake scripts seem to work much better for the dynamic build and when using it with an application.
So yeah, I am interesting in whether the Ogre3D developers have themselves gotten the static version working, and have they created an application which works with it? It would be very helpful if there was an example script for an application when using a static build of Ogre3D. I will promise not to give up just yet with it, I will keep working and learning about cmake so I could fix the errors by myself if possible, but it would be helpful to know if someone knows for a fact it works like intended with an application.
I am talking of doing it all on Linux - on Debian 5 specifically.
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: CMake build system for Cthugha *looking for testers*
A while back I did a static build (on Linux/Ubuntu), and it worked in so far as all the samples were running fine. I haven't tested it with a custom app because I have no use for a statically linked version, myself. Also, there are enough configurations for me to test out, so seeing as I don't own a quad core, I have no compile time to regularly test a static build, myself
-
- Ogre Magi
- Posts: 1120
- Joined: Wed Nov 15, 2006 7:41 pm
- Location: Finland
- x 5
Re: CMake build system for Cthugha *looking for testers*
That's okay I understand.
I was just curious whether it has been tested at all since I was having quite a lot of problems with it.
I can't believe it should be so hard as it has been here so something is not going right - I just don't know what I will keep trying, though.
I was just curious whether it has been tested at all since I was having quite a lot of problems with it.
I can't believe it should be so hard as it has been here so something is not going right - I just don't know what I will keep trying, though.
-
- Gnoblar
- Posts: 21
- Joined: Tue Sep 15, 2009 12:11 pm
Re: CMake build system for Cthugha *looking for testers*
Hi !
Is it possible to build OGRE 1.7 from svn without using CMake ?
Or is there going to be included any other build systems in the future ?
This is because cmake doesn't work with new Maemo Linux 5 when developing for Mobile devices.
cmake is broken there and I believe that developers have no hurry to fix it.
Is it possible to build OGRE 1.7 from svn without using CMake ?
Or is there going to be included any other build systems in the future ?
This is because cmake doesn't work with new Maemo Linux 5 when developing for Mobile devices.
cmake is broken there and I believe that developers have no hurry to fix it.
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: CMake build system for Cthugha *looking for testers*
You want to compile Ogre *on* the mobile device itself? I though usually you'd want to cross-compile from your desktop PC, in which case it should be irrelevant whether or not cmake runs on the mobile itself.
In any case, the plan is for cmake to be the only officially included and supported build system for Ogre. You can, of course, create your own if you really need to. I would, however, say that the time is better spent fixing the original issue with cmake.
In any case, the plan is for cmake to be the only officially included and supported build system for Ogre. You can, of course, create your own if you really need to. I would, however, say that the time is better spent fixing the original issue with cmake.
-
- Gnoblar
- Posts: 21
- Joined: Tue Sep 15, 2009 12:11 pm
Re: CMake build system for Cthugha *looking for testers*
I want to compile OGRE in scratchbox on ARMEL target.You want to compile Ogre *on* the mobile device itself? I though usually you'd want to cross-compile from your desktop PC, in which case it should be irrelevant whether or not cmake runs on the mobile itself.
In any case, the plan is for cmake to be the only officially included and supported build system for Ogre. You can, of course, create your own if you really need to. I would, however, say that the time is better spent fixing the original issue with cmake.
so I'm doing cross-compile on my PC.. and I think there is no other way to get OGRE libs for mobile device which uses ARMEL architecture.
but if there is no other plans for future I had to just wait for a while.
CMake has worked there before and I believe it will work again some day.. It is still used on many projects.
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: CMake build system for Cthugha *looking for testers*
Not sure what scratchbox does, but I still fail to see the problem. If you're doing a cross-compile, then all you need to do is to tell CMake to generate Makefiles for a different compiler toolchain. CMake can and will run natively on your desktop PC. So what exactly is it you need to do which doesn't work?
- Assaf Raman
- OGRE Team Member
- Posts: 3092
- Joined: Tue Apr 11, 2006 3:58 pm
- Location: TLV, Israel
- x 76
Re: CMake build system for Cthugha *looking for testers*
Seems this is scratchbox.
Watch out for my OGRE related tweets here.
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Re: CMake build system for Cthugha *looking for testers*
If they don't support CMake, they are doing it wrong.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
- Brocan
- Orc
- Posts: 441
- Joined: Tue Aug 01, 2006 1:43 am
- Location: Spain!!
- x 8
Re: CMake build system for Cthugha *looking for testers*
I don't know if it has been said or it's only my problem, but, cmake doesn't include the paths to dx10 libs into dx10 render system.
Last trunk revision at this moment and visual studio 2008.
Last trunk revision at this moment and visual studio 2008.
- DaesDemon
- Goblin
- Posts: 209
- Joined: Thu Jan 22, 2004 3:59 pm
- Location: Toulouse (France)
Re: CMake build system for Cthugha *looking for testers*
I confirm that dx10_RenderSystemhaven't the complete path for dx10 libs (unlike dx9) in vs2005 too.
Strangely i was unable to link the SampleBrowser without dx10_RenderSystem linked even if i am on XP
Strangely i was unable to link the SampleBrowser without dx10_RenderSystem linked even if i am on XP
-
- Ogre Magi
- Posts: 1120
- Joined: Wed Nov 15, 2006 7:41 pm
- Location: Finland
- x 5
Re: CMake build system for Cthugha *looking for testers*
FYI, I did get a dynamic build working so that it doesn't crash on app exit. I did a test that I did not touch a single setting of Ogre3D, and compiled, and that build works. Now I should go and iterate over the changes I did, one-by-one, to see which one caused it to break, or possibly a combination of changes. I mean it produced a build which made the app crash on exit, with very simple code in the app (just fire up ogre root and renderwindow and a loop to run it, can't see anything wrong in my code so it was very weird it was crashing). I'll need to do some more research to see what change of a setting caused it to break. It's pretty tough work - perhaps I am forced to settle for using the default configuration, although it stings my soul a little bit nah, definitely I'll investigate more what was going wrong.
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: CMake build system for Cthugha *looking for testers*
@reptor: Crashes on exit are almost always caused by incorrect linking, i. e. the linker picks up a wrong version of the Ogre libraries (which do not fit to the headers you're building against), and that causes havoc on all sorts of things. More often than not, you'll experience weird crashes in particular on app shutdown.
This can also happen if you pull in plugins which were compiled against a different OgreMain. So, double-check your paths if such things happen
@DirectX: The DX find script is generally lacking atm, I will fix this eventually, I'm just a bit off my game currently, so have a little patience
This can also happen if you pull in plugins which were compiled against a different OgreMain. So, double-check your paths if such things happen
@DirectX: The DX find script is generally lacking atm, I will fix this eventually, I'm just a bit off my game currently, so have a little patience
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: CMake build system for Cthugha *looking for testers*
Hi! This is my first [s]nightmare[/s] time with CMake.
From latest SVN (9181) I noticed that:
* CMake refuses to create the VC2005 projects if Cg.dll isn't present in "Samples\Common\bin\Release" & debug folders. Same happens with OIS.dll & OIS_d.dll
* It would be nice to have an option to enable the "/MP" flag on VC2005+ so that compiling time takes less (OgreMain specially)
* If zlib dependency isn't found, it says it's optional, but you get then linking errors in OgreMain
* Someone correct me if I'm wrong, but I don't see the option to use the dynamic dll version of FreeImage to link against (by default, it defines FREEIMAGE_LIB which makes Ogre use a static library, causing linking errors if you have the dynamic one)
That's it for now. I'm still waiting it to compile successfully
From latest SVN (9181) I noticed that:
* CMake refuses to create the VC2005 projects if Cg.dll isn't present in "Samples\Common\bin\Release" & debug folders. Same happens with OIS.dll & OIS_d.dll
* It would be nice to have an option to enable the "/MP" flag on VC2005+ so that compiling time takes less (OgreMain specially)
* If zlib dependency isn't found, it says it's optional, but you get then linking errors in OgreMain
* Someone correct me if I'm wrong, but I don't see the option to use the dynamic dll version of FreeImage to link against (by default, it defines FREEIMAGE_LIB which makes Ogre use a static library, causing linking errors if you have the dynamic one)
That's it for now. I'm still waiting it to compile successfully
- aguru
- Goblin
- Posts: 236
- Joined: Tue Feb 26, 2008 5:48 pm
- x 3
Re: CMake build system for Cthugha *looking for testers*
Compiling ogre on x64 linux I get this error - any idas? Is it a bug in the cmake config?
Code: Select all
Linking CXX shared library ../../lib/Sample_Terrain.so
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/../../../../x86_64-pc-linux-gnu/bin/ld: ../../lib/libOgreTerrain.a(OgreTerrain.cpp.o): relocation R_X86_64_32 against `Ogre::StringUtil::BLANK' can not be used when making a shared object; recompile with -fPIC
../../lib/libOgreTerrain.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[2]: *** [lib/Sample_Terrain.so] Error 1
make[1]: *** [Samples/Terrain/CMakeFiles/Sample_Terrain.dir/all] Error 2
make: *** [all] Error 2
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: CMake build system for Cthugha *looking for testers*
Hm, it looks like you're compiling statically? Try a dynamic build, statically linking seems to have very specific problems on x64 Linux architectures.
Ultimately I need to install an x64 Linux system and experiment with this myself.
Ultimately I need to install an x64 Linux system and experiment with this myself.