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
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

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

Post by Kojack »

Unfortunately Cmake has no support for the Intel C++ compiler hosted within Visual Studio.
But the end result after generating a visual studio 2008 solution can be converted into an Intel solution by right clicking on the solution in the solution browser in VS and selecting the convert to Intel option. It makes a bit of a mess (every project becomes the child of a new project), but otherwise it's fine.
I don't know how that's going to work with all the extra cmake stuff that gets done when you build though, if the cmake files change and it decided to update the solution it will probably wipe the intel compiler out again.
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 »

Hmm - my feeling is that CMake doesn't make this any worse than the old situation of manually defined projects, so is unfortunate but unavoidable right now.
User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 99
Contact:

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

Post by Wolfmanfx »

I like CMake :D work like a charm on OSX really great work
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

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

Post by Kojack »

I was just curious if it worked. It's a bit surprising that cmake has 18 compiler choices but doesn't include the Intel compiler, which is pretty well known and available for both windows and linux (and even available for free if you are doing non commercial linux development).

But the difference between generating a visual studio solution with cmake and generating an intel solution hosted in visual studio with cmake is 3 mouse clicks, so that's not too bad, and I don't actually intend to keep using it anyway. :)
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 »

Hm, I think the key to using a different compiler with CMake is in the configuration phase.
When you prepare a new build dir and click on "Configure" for the first time, the dialog opens where you select the CMake generator to use. Here you need to select "Compiler Setup" instead of "Use Defaults", and then you can specify a different compiler. Worth a shot, at least :)
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 »

Wolfmanfx wrote:I like CMake :D work like a charm on OSX really great work
Phew - I only just got it working properly on OS X last weekend so I'm glad it works for someone else too :)
muller
Halfling
Posts: 71
Joined: Sat May 28, 2005 10:44 pm
Location: Kishinev, Moldova
Contact:

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

Post by muller »

Mmm.. look like incorrect detection of DXSDK directory.

To corectly generate build scripts for D3D9 and D3D10 rendersystems, had to remove additional search directories, and rely on DXSDK_DIR enviromental variable only.

Code: Select all

Index: FindDirectX.cmake
===================================================================
--- FindDirectX.cmake	(revision 8513)
+++ FindDirectX.cmake	(working copy)
@@ -14,10 +14,6 @@
   # Example of path is C:\apps_x86\Microsoft DirectX SDK (August 2008)\Include
   find_path(DirectX_INCLUDE_DIR d3d9.h
     "$ENV{DXSDK_DIR}/Include"
-    "C:/apps_x86/Microsoft DirectX SDK*/Include"
-    "C:/Program Files (x86)/Microsoft DirectX SDK*/Include"
-    "C:/apps/Microsoft DirectX SDK*/Include"
-    "C:/Program Files/Microsoft DirectX SDK*/Include"
     )
   mark_as_advanced(DirectX_INCLUDE_DIR)
   if(DirectX_INCLUDE_DIR)


The other option, is to change the path order, as it tries to search in all directories, and does not stop.
The d3d9.h header is also located withing Windows SDK directories, which is getting picked up, although the correct DXSDK_DIR is located elsewhere.
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 »

Hm no, the script is just doing the search wrong. This is one of two Find scripts we pulled from outside, and it's not conforming to the way the other scripts work. I'll fix that.
User avatar
xadhoom
Minaton
Posts: 973
Joined: Fri Dec 28, 2007 4:35 pm
Location: Germany
x 1

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

Post by xadhoom »

Hi Cabalistic!

Thanks for your work on the CMake port. I didn´t know how useful it is until Ogre :-)
One thing I experienced using it (VS2005) is that excluding the ParticleFX plugin and including
the media folder makes some Samples useless (exception on startup) because there are particle scripts which are not
supported by Ogre directly.

Is it possible/worth to prevent generating these media files depending on the ParticleFX settings as well?

Thanks, xad
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, but it's possible to disable building those samples which depend on the presence of a certain plugin. I just need to assemble a list of which sample needs what plugins (or for somebody to provide me that list :) ).
User avatar
xadhoom
Minaton
Posts: 973
Joined: Fri Dec 28, 2007 4:35 pm
Location: Germany
x 1

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

Post by xadhoom »

I fear all samples use the same resources.cfg. No demo sample works if you do not build the ParticleFX plugin.

xad
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 »

Really? As long as the demo doesn't use the particles, shouldn't any problems loading the particle resource be treated as non-fatal? At least that's how materials and shaders work which I think is sensible.
User avatar
xadhoom
Minaton
Posts: 973
Joined: Fri Dec 28, 2007 4:35 pm
Location: Germany
x 1

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

Post by xadhoom »

That does not seem to apply in this case. Just comment out the line "Plugin=Plugin_ParticleFX" in Plugins.cfg in the sample folder and you will get an exception for every Demo. So, if you don´t create the Plugin with cmake you will run into this issue.

xad
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 »

Hm, you're right. Seems inconsistent to me, though.
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 »

created a simple template for projects that use Ogre:

Code: Select all

FILE(GLOB_RECURSE myapp_src *.cpp)
FILE(GLOB_RECURSE myapp_headers *.h)

include_directories(${OgreMain_SOURCE_DIR}/include)

add_executable(myapp ${myapp_src} ${myapp_headers})

target_link_libraries(myapp OgreMain)
add_dependencies(myapp Ogre)
you will also need a top-level CMake file that joins the projects together
User avatar
cdleonard
Goblin
Posts: 266
Joined: Thu May 31, 2007 9:45 am

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

Post by cdleonard »

I got around to looking at CMake again.

- All libs go in sdk/lib; not like sdk/bin/$config. This makes it impossible to differentiate between stuff like Release and RelWithDebInfo. It's also not symmetrical. :)
- Demo pdbs are always installed; even if OGRE_INSTALL_DEMOS is false.
- The octree plugin includes private headers like '#include <OgreHeader.h>'. This forces you to add the full plugin include path. Doing the same thing with 'include "OgreHeader.h"' looks in the current directory first (there are some other platform-specific differences). Not really related to cmake.

Also; on linux it seems that plugins were moved from $prefix/lib/OGRE to $prefix/lib. This makes `pkg-config OGRE --variable=plugin-dir` a liar.

These are minor issues. Otherwise the system seems to work great; very useful addition.
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 »

cdleonard wrote: - All libs go in sdk/lib; not like sdk/bin/$config. This makes it impossible to differentiate between stuff like Release and RelWithDebInfo. It's also not symmetrical. :)
That's the structure of previous SDK builds, I didn't want to change that. Besides, for SDK builds I don't think it's really feasible to have more than one release type build present. You can always use the build directory if you want to use a specific build type :)
- Demo pdbs are always installed; even if OGRE_INSTALL_DEMOS is false.
Fixed, thanks.
Also; on linux it seems that plugins were moved from $prefix/lib/OGRE to $prefix/lib. This makes `pkg-config OGRE --variable=plugin-dir` a liar.
That was not intended, I simply didn't notice that a recent fix to the CMake build files changed the behaviour on Linux. Fixed.
jonim8or
Goblin
Posts: 287
Joined: Mon Dec 08, 2008 4:49 pm
x 10

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

Post by jonim8or »

I needed this change to allow it to find the header files of the plugins and rendersystems:

Code: Select all

Index: CMake/Packages/FindOGRE.cmake
===================================================================
--- CMake/Packages/FindOGRE.cmake	(revision 8530)
+++ CMake/Packages/FindOGRE.cmake	(working copy)
@@ -246,11 +246,23 @@
     set(CMAKE_FIND_LIBRARY_PREFIXES ${CMAKE_FIND_LIBRARY_PREFIXES} "")
   endif()
   
-  # header files for plugins are optional
-  set(OGRE_PLUGIN_PATH_SUFFIXES
-    PlugIns PlugIns/${PLUGIN} ${PLUGIN} ${ARGN})
+  #set the plugin search path suffixes correctly. 
+  #assumes that when plugins are in a subdir for their type (RenderSystem or Plugin),
+  #they won't have their corresponding prefix. (which is also how the include dirs are currently organized)
+  string(REGEX MATCH "^RenderSystem_" PLUGIN_IS_RENDERSYSTEM ${PLUGIN})
+  string(REGEX MATCH "^Plugin_" PLUGIN_IS_PLUGIN ${PLUGIN})
+  if(PLUGIN_IS_RENDERSYSTEM)
+      string(REPLACE "RenderSystem_" "" STRIPPED_PLUGIN_NAME ${PLUGIN})
+      set(OGRE_PLUGIN_PATH_SUFFIXES
+        RenderSystems RenderSystems/${STRIPPED_PLUGIN_NAME} ${PLUGIN} ${ARGN})
+  elseif(PLUGIN_IS_PLUGIN)      
+      string(REPLACE "Plugin_" "" STRIPPED_PLUGIN_NAME ${PLUGIN})
+      set(OGRE_PLUGIN_PATH_SUFFIXES
+        Plugins Plugins/${STRIPPED_PLUGIN_NAME} ${PLUGIN} ${ARGN})
+  endif()
+  
   find_path(OGRE_${PLUGIN}_INCLUDE_DIR NAMES ${HEADER} 
-    HINTS ${OGRE_INCLUDE_DIRS} ${OGRE_PREFIX_SOURCE}  
+    PATHS ${OGRE_INCLUDE_DIRS} ${OGRE_PREFIX_SOURCE}  
     PATH_SUFFIXES ${OGRE_PLUGIN_PATH_SUFFIXES})
   # find link libraries for plugins
   set(OGRE_${PLUGIN}_LIBRARY_NAMES "${PLUGIN}${OGRE_LIB_SUFFIX}")
@@ -304,7 +316,7 @@
 
 ogre_find_plugin(Plugin_PCZSceneManager OgrePCZSceneManager.h PCZ PlugIns/PCZSceneManager/include)
 ogre_find_plugin(Plugin_OctreeZone OgreOctreeZone.h PCZ PlugIns/OctreeZone/include)
-ogre_find_plugin(Plugin_BSPSceneManager OgreBSPSceneManager.h PlugIns/BSPSceneManager/include)
+ogre_find_plugin(Plugin_BSPSceneManager OgreBspSceneManager.h PlugIns/BSPSceneManager/include)
 ogre_find_plugin(Plugin_CgProgramManager OgreCgProgram.h PlugIns/CgProgramManager/include)
 ogre_find_plugin(Plugin_OctreeSceneManager OgreOctreeSceneManager.h PlugIns/OctreeSceneManager/include)
 ogre_find_plugin(Plugin_ParticleFX OgreParticleFXPrerequisites.h PlugIns/ParticleFX/include)
Btw, the plugin headers can be installed, but currently the rendersystem headers are not. In the above changes I assume they are placed in a RenderSystems directory, in a way similar to the Plugin headers.
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 »

Why exactly would you need the headers of the rendersystems? In principle, both plugins and rendersystems are meant to go without explicit linking and, therefore, without needing their headers. I recognise there are some rare exceptions for some of the plugins, hence why you can install and find them. But I couldn't think of a good reason to link against the rendersystems which is why I excluded them. They are, after all, slightly more complicated to setup right because they contain platform-specific headers.
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

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

Post by Kojack »

Not sure about jonim8or's reason, but using Cuda with Ogre requires the render system plugin headers.
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 »

Alright, I'll put it on my todo, then.
User avatar
cdleonard
Goblin
Posts: 266
Joined: Thu May 31, 2007 9:45 am

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

Post by cdleonard »

CABAListic wrote:
cdleonard wrote: - All libs go in sdk/lib; not like sdk/bin/$config. This makes it impossible to differentiate between stuff like Release and RelWithDebInfo. It's also not symmetrical. :)
That's the structure of previous SDK builds, I didn't want to change that. Besides, for SDK builds I don't think it's really feasible to have more than one release type build present. You can always use the build directory if you want to use a specific build type :)
The structure of previous SDK builds is not perfect; and there were other changes anyway. It seems like a worthwhile change; and one that is very easy to compensate for (just add both lib and lib/$config) to lib paths. Even if ogre doesn't currently provide hybrid builds for fast debugging it might want to in the future. Doing this change now makes that possible without future breakages :).
iFire
Gnoblar
Posts: 24
Joined: Mon Sep 26, 2005 6:39 am
x 1

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

Post by iFire »

Both Building From Source and Building with CMake seem to be doing the same role. Can we edit it so that they are united?
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, at least not while the CMake build system and its documentation are still work in progress. That would make it harder for me to fill in the blanks or update information. Afterwards we can see what should go where, but right now this is my "draft place" :)
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 »

iFire wrote:Both Building From Source and Building with CMake seem to be doing the same role. Can we edit it so that they are united?
Not while the stable version is v1.6, since that doesn't have CMake. Once 1.8 is released we can switch over which is the 'primary' reference and relegate the old Building From Source page to a previous version.
Locked