CMake build system for Cthugha *looking for testers*

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
Locked
User avatar
jacmoe
OGRE Retired Moderator
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*

Post by jacmoe »

I guess the instructions in FindOGRE.cmake needs changing.
It should say:
# For each of these components, the following variables are defined:
#
# OGRE_${COMPONENT}_FOUND - ${COMPONENT} is available
# OGRE_${COMPONENT}_INCLUDE_DIR - additional include directory for ${COMPONENT}
# OGRE_${COMPONENT}_LIBRARY - link this to use ${COMPONENT}
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
CABAListic
OGRE Retired Team Member
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*

Post by CABAListic »

No, it shouldn't - those variables are intermediary. It's simply a bug that the final ones are not set ;)
User avatar
jacmoe
OGRE Retired Moderator
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*

Post by jacmoe »

Alright. I'll leave you to it.
At least it works now - I just compiled the whole Ogitor framework using CMake on Windows and on Linux.
Thanks for the scripts! :)
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Enrico
Gnoblar
Posts: 20
Joined: Thu Jun 07, 2007 12:44 pm

Re: CMake build system for Cthugha *looking for testers*

Post by Enrico »

Quote - So the cmake scripts work fine on Red Hat 5.3. Any suggestions for the problem on my Debian box? :(
CABAListic
OGRE Retired Team Member
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*

Post by CABAListic »

Have you tried disabling boost (i. e. disable threading and disable OGRE_USE_BOOST)? The error messages appear to suggest that something's wrong with your boost libraries.
User avatar
tdev
Silver Sponsor
Silver Sponsor
Posts: 244
Joined: Thu Apr 12, 2007 9:21 pm
Location: Germany
x 14

Re: CMake build system for Cthugha *looking for testers*

Post by tdev »

i was recently porting myGUI and paged geometry to cmake and got some problems which i thought should be solved together:

- File replicating: i propose we should open a google code project that just contains the CMake files required for self-standing addons. This way you can fix all addons at once and still export the svn with externals. Do you have better ideas?

- addons cmake simplification: instead of doing it the OgreMain way of defining everything we could add some simple functions that do most of the work and hide the ugly GXX and macos "hacks"

- plugin-ability of addons and OgreMain (only) into a common project, thus not using FindOgre.cmake, but rather using the existing targets directly. Best solution would be to detect and used the best way automatically.

- plugin-ability of media and additional files for addons

- minimizing the Ogre Cmake to the pure basics by a parent cmake file - possible?

Do you have any better ideas / concepts? Anything i overlooked?
User avatar
jacmoe
OGRE Retired Moderator
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*

Post by jacmoe »

I am not really sure what you're talking about?
If you install Ogre, it will install a set of cmake files which you can use.
You just grab the files, include them in your cmake script, call find_package(OGRE) - and you're ready to use the CMake variables returned.
I don't know what else there is to want? :)

On Linux, by default, the scripts are installed to /usr/local/lib/OGRE/cmake. If on Windows, they're installed to Ogre_SDK/CMake.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
DigitalGhost
Halfling
Posts: 62
Joined: Mon Feb 07, 2005 9:47 pm

Re: CMake build system for Cthugha *looking for testers*

Post by DigitalGhost »

One gripe I have about the cmake build system for ogre is that is doesn't put debug files either (1) in their own directory or (2) with a _d at the end. At least it doesn't do this for my OS (mac osx). As a result, the debug and release builds overwrite each other when I try to install.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: CMake build system for Cthugha *looking for testers*

Post by sinbad »

DigitalGhost wrote:One gripe I have about the cmake build system for ogre is that is doesn't put debug files either (1) in their own directory or (2) with a _d at the end. At least it doesn't do this for my OS (mac osx). As a result, the debug and release builds overwrite each other when I try to install.
I'm using Mac OSX and debug and release are in their own folders and happily co-exist (_d is not used because Frameworks typically don't use this approach because it breaks the header paths). However, I generally don't run the install process because everything runs just fine from the build area, perhaps that is the issue. I'd planned on looking at that when I came to doing the SDK, which is all the install step is really for.
DigitalGhost
Halfling
Posts: 62
Joined: Mon Feb 07, 2005 9:47 pm

Re: CMake build system for Cthugha *looking for testers*

Post by DigitalGhost »

sinbad wrote:
DigitalGhost wrote:One gripe I have about the cmake build system for ogre is that is doesn't put debug files either (1) in their own directory or (2) with a _d at the end. At least it doesn't do this for my OS (mac osx). As a result, the debug and release builds overwrite each other when I try to install.
I'm using Mac OSX and debug and release are in their own folders and happily co-exist (_d is not used because Frameworks typically don't use this approach because it breaks the header paths). However, I generally don't run the install process because everything runs just fine from the build area, perhaps that is the issue. I'd planned on looking at that when I came to doing the SDK, which is all the install step is really for.
I think the install target is the problem. When I build the code, it puts it in the debug or release directory as a subdirectory of the project file, but when I build the install target, it installs everything to one directory. The debug and release libraries get collapsed into one folder.
User avatar
tdev
Silver Sponsor
Silver Sponsor
Posts: 244
Joined: Thu Apr 12, 2007 9:21 pm
Location: Germany
x 14

Re: CMake build system for Cthugha *looking for testers*

Post by tdev »

jacmoe wrote:I am not really sure what you're talking about?
If you install Ogre, it will install a set of cmake files which you can use.
You just grab the files, include them in your cmake script, call find_package(OGRE) - and you're ready to use the CMake variables returned.
I don't know what else there is to want? :)

On Linux, by default, the scripts are installed to /usr/local/lib/OGRE/cmake. If on Windows, they're installed to Ogre_SDK/CMake.
if you want to see what i am about, SVN-checkout this:
https://rigsofrods.svn.sourceforge.net/ ... _ogre_head

or view it online:
http://rigsofrods.svn.sourceforge.net/v ... ogre_head/

this is not using find_package(Ogre)
the ogre coupling in this buildsystem is done there: http://rigsofrods.svn.sourceforge.net/v ... iew=markup

i was basically thinking about to improve the include-ability into a top level project.
User avatar
jacmoe
OGRE Retired Moderator
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*

Post by jacmoe »

I prefer that Ogre behaves the same was as any other standard CMake find_package module.
In qtOgitor, we do find_package(QT) and a find_package(OGRE), and that's it.

Except for the Mac, where we have an additional find_package(CG).

When we used wxWidgets, we did a find_package(WXWIDGETS) and find_package(GTK2)

((All this is IIRC)).

While I have a suspicion that we're not talking about the same thing here, I really don't see the need to go into the internal Ogre CMake scripts and mess with them.

<edit>
OK, I get it.
You are talking about making Ogre a sub-project of your own project.
Well, each to his own.. :wink:

Fair enough - I get it now. :)
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Enrico
Gnoblar
Posts: 20
Joined: Thu Jun 07, 2007 12:44 pm

Re: CMake build system for Cthugha *looking for testers*

Post by Enrico »

I get the same linker error on a recent Gentoo system as I have on my Debian box :(
Ideas?

Boost and threading is disabled right now. However, this does not install the samples, even if it is selected in ccmake :?:
User avatar
jacmoe
OGRE Retired Moderator
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*

Post by jacmoe »

On my machine, the samples are installed to /usr/local/share/OGRE/samples and /usr/local/share/OGRE/media :wink:
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
tdev
Silver Sponsor
Silver Sponsor
Posts: 244
Joined: Thu Apr 12, 2007 9:21 pm
Location: Germany
x 14

Re: CMake build system for Cthugha *looking for testers*

Post by tdev »

jacmoe wrote: OK, I get it.
You are talking about making Ogre a sub-project of your own project.
Well, each to his own.. :wink:

Fair enough - I get it now. :)
thanks for trying to understand :)
i think we will provide our software in a fallback way: if find_package(X) is not found, the attached source code will be added and compiled.
so, "make" will do the right thing, even if dependencies are not intalled.
Enrico
Gnoblar
Posts: 20
Joined: Thu Jun 07, 2007 12:44 pm

Re: CMake build system for Cthugha *looking for testers*

Post by Enrico »

jacmoe wrote:On my machine, the samples are installed to /usr/local/share/OGRE/samples and /usr/local/share/OGRE/media :wink:
There are no samples installed, I am sure ;)

Oh, I see there is already another thread created especially for this problem...

Is there a specific reason why you link against static boost libraries?

I think I found the problem: When enabling threading in (c)cmake, you still want to link against the single-threaded library versions. However, you should link against the multithreaded versions. I manually changed the libraries from:

Code: Select all

Boost_DATE_TIME_LIBRARY: /usr/lib64/libboost_date_time.a
Boost_THREAD_LIBRARY: /usr/lib64/libboost_thread.a
to

Code: Select all

Boost_DATE_TIME_LIBRARY: /usr/lib64/libboost_date_time-mt.so
Boost_THREAD_LIBRARY: /usr/lib64/libboost_thread-mt.so
And now it compiles and links =)
User avatar
Kencho
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4011
Joined: Fri Sep 19, 2003 6:28 pm
Location: Burgos, Spain
x 2
Contact:

Re: CMake build system for Cthugha *looking for testers*

Post by Kencho »

Okay, finally decided to give CMake a try with the SVN version, and for some reason I can't build the OpenGL render system plugin. CMake just can't find the package, although it's actually there.

Code: Select all

$ pkg-config --modversion gl
7.3.0
So tried to add a package to the scripts strongly based on the OpenGLES script. The script is included correctly, and it reaches the point where it looks for the library (it outputs messages deliberately set there). However, FIND_LIBRARY doesn't find it at all.

Using pkg_check_modue (OPENGL gl) actually works (the variables OPENGL_FOUND, OPENGL_LIBRARY_DIRS, etc. are set as expected) and I can "cheat" the script so that it's actually found, but the filename isn't set as expected, so it can't be built.

I've also tried adding the CMake standard script FindOpenGL.cmake but had no luck (even using a raw URI it doesn't find the library either).

Is anyone else having this same problem? Where is GL_CM (well, in the original script, GLES_CM) set?

As you'll probably find this useful, here's the OS info:

Code: Select all

$ uname -srvo
Linux 2.6.28-13-generic #45-Ubuntu SMP Tue Jun 30 19:49:51 UTC 2009 GNU/Linux
Image
User avatar
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*

Post by Brocan »

I don't know if i make a mistake or its a bug or what, but the dx library path doesn't add into the extra lib dependencies in vs2009.

And Cmake says: DirectX_D3DX9_LIBRARY: C:/Program Files/Microsoft DirectX SDK (November 2008)/Lib/x86/d3dx9.lib

Cheers!
T0NY
Gnoblar
Posts: 4
Joined: Fri Jul 24, 2009 5:50 am

Re: CMake build system for Cthugha *looking for testers*

Post by T0NY »

Enrico wrote:I get the same linker error on a recent Gentoo system as I have on my Debian box :(
Ideas?

Boost and threading is disabled right now. However, this does not install the samples, even if it is selected in ccmake :?:
This error happened because boost libraries was compiled without -fPIC. You need to compile boost with fPIC or to compile Ogre libraries without it. There is discussion about the same problem with boost developer - http://lists.boost.org/boost-users/2009/03/45895.php .
psquare
Hobgoblin
Posts: 554
Joined: Tue Nov 14, 2006 3:26 pm
x 7

Re: CMake build system for Cthugha *looking for testers*

Post by psquare »

Maybe I missed something in this post, but I have to manually set these flags in buildsettings.h (would like to build with thread support and boost) after configure and generate:

#define OGRE_THREAD_SUPPORT 1
#define OGRE_USE_BOOST 1

I couldn't find an option to configure these 2 via the gui.

Also, I do set the boost include path and the date-time/thread dir paths in the cmake gui, and then hit configure again. But this reverts the library paths to their old values (not found). As such, I have to add the boost header and the lib directories' paths (I build my own) via Tools->Options->Projects and Solutions->VC++ dirs, something which I don't want to do.

In any case, I am able to build and run with thread support and boost, so this is not a huge deal. Just reporting/testing.

Again, apologies if I overlooked something obvious.

<Edit/>
Environment:
-VS 2008
-XP
-Latest cmake
-Ogre Trunk
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: CMake build system for Cthugha *looking for testers*

Post by sinbad »

psquare wrote:Maybe I missed something in this post, but I have to manually set these flags in buildsettings.h (would like to build with thread support and boost) after configure and generate:

#define OGRE_THREAD_SUPPORT 1
#define OGRE_USE_BOOST 1

I couldn't find an option to configure these 2 via the gui.
You need to set OGRE_CONFIG_THREADS in the CMake gui. The easy way to find settings is to type a pattern in the 'search' bar at the top to filter.

As for Boost, OGRE_USE_BOOST is set to 1 automatically so long as Boost is found during the Configure step. You can add a BOOST_ROOT entry to your CMake config (just hit the 'Add Entry' button on the top right) to point it at Boost, or define that in your environment variables (although that seems to take a reboot to pick up on Windows rather than just a Cmake restart as I'd expect). I prefer to set it per build environment personally, in case specific projects are still using particular versions.
psquare
Hobgoblin
Posts: 554
Joined: Tue Nov 14, 2006 3:26 pm
x 7

Re: CMake build system for Cthugha *looking for testers*

Post by psquare »

sinbad wrote: You can add a BOOST_ROOT entry to your CMake config (just hit the 'Add Entry' button on the top right) to point it at Boost
That does the trick! This also exposes the OGRE_CONFIG_THREADS in the gui, which explains why I couldn't find it earlier via the search bar. Its all good now.
Thanks!
Fulmens
Gremlin
Posts: 151
Joined: Sun Jun 22, 2008 8:29 pm
Location: Nantes, France
x 1

Re:

Post by Fulmens »

I've only a basic understanding of CMake, but I have trouble using it for the latest SVN version.
I'm building scripts for VS2005, but when trying to compile, there is a failure for the D3D render systems.
Basically, d3d9.lib and d3d10.lib are added in the properties of the project, but not the directories in the "Additional Library Directories".

I found this earlier post of PolyVox :
PolyVox wrote:I tried it on Windows and it basically worked with a couple of problems.

Firstly the Direct3D9 RenderSystem didn't build because it couldn't find the .lib. This was a simple oversight, as the variable 'DirectX_LIBRARY_PATHS' had been defined by the FindDirectX.cmake script but wasn't being used. I fixed this by adding:

Code: Select all

link_directories(${DirectX_LIBRARY_PATHS})
to the Direct3D9 CmakeLists.txt

Secondly, it didn't find OIS or CEGUI and so was unable to build the samples. I didn't know how to fix this because I didn't know how it was trying to find them (I didn't see a FindOIS.cmake file). Any tips?

It didn't find Cg either, but I can investigate that a bit.
From what I've seen in CMake files, there is always "link_directories(${DirectX_LIBRARY_PATHS})" in the CMakeLists.txt in the directory of the D3D9 render system, but in the FIndDirectX.cmake in CMake/Packages on svn, between revision 8449 and 8520,

Code: Select all

  set(DirectX_LIBRARY_PATHS)
  if(CMAKE_CL_64)
    set(DirectX_LIBRARY_PATHS 
      "${DirectX_ROOT_DIR}/Lib/x64")
  else(CMAKE_CL_64)
    set(DirectX_LIBRARY_PATHS 
      "${DirectX_ROOT_DIR}/Lib/x86" "${DirectX_ROOT_DIR}/Lib")
  endif(CMAKE_CL_64)
has been changed to

Code: Select all

  if(CMAKE_CL_64)
    set(DirectX_LIBPATH_SUFFIX "x64")
  else(CMAKE_CL_64)
    set(DirectX_LIBPATH_SUFFIX "x86")
  endif(CMAKE_CL_64)
And DirectX_LIBRARY_PATHS is nowhere else to be found in the Ogre directory.
Moreover I don't know why but Cmake doesn't seem to be able to assign a value to DirectX_ROOT_DIR. It is marked as "NOT_FOUND" in the cache, where DirectX_INCLUDE_DIR from which it seems to be derived is ok. So even with the above code DirectX_LIBRARY_PATHS woulnd't work.
Strangely, I can't manually change the value of DirectX_ROOT_DIR, clicking configure resets it's value to NOT_FOUND and generate is disabled when a change is made in a value...And why is DirectX_INCLUDE_DIR defined as PATH in CMakeCache and DirectX_ROOT_DIR as STRING ?
I'm gonna end adding the path to lib directories manually in VS2005, but what am I missin here ?
CABAListic
OGRE Retired Team Member
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*

Post by CABAListic »

Possibly some bug in the DirectX find script. It's one of the uglier ones, and I've kind of been thinking about rewriting it ever since :)
Anyway, I have been absent for the last few weeks due to exams, but I'm slowly getting back to the game, so give me a few days, and I'll see what I can do about that script.
razor950
Gnoblar
Posts: 9
Joined: Sat Jun 24, 2006 8:56 pm

Re: CMake build system for Cthugha *looking for testers*

Post by razor950 »

I like the cmake build system very much but I seem to have a issue with getting boost to show up. I have checked my register, and installpath is correct.
I also did the following and nothing. Boost-Threads shows up but Boost doesn't and I even tried to manually put those in cmake as well, nothing either.

Code: Select all

setx BOOST_ROOT C:\dev\boost\boost_1_39
setx BOOST_LIBRARYDIR C:\dev\boost\boost_1_39\lib
setx BOOST_INCLUDEDIR C:\dev\boost\boost_1_39\boost
I have installed boost twice just incase it was something I missed.
Locked