Page 10 of 20
Re: CMake build system for Cthugha *looking for testers*
Posted: Fri Apr 10, 2009 12:02 pm
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.
Re: CMake build system for Cthugha *looking for testers*
Posted: Fri Apr 10, 2009 5:03 pm
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.
Re: CMake build system for Cthugha *looking for testers*
Posted: Fri Apr 10, 2009 6:05 pm
by Wolfmanfx
I like CMake
work like a charm on OSX really great work
Re: CMake build system for Cthugha *looking for testers*
Posted: Fri Apr 10, 2009 7:25 pm
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.
Re: CMake build system for Cthugha *looking for testers*
Posted: Fri Apr 10, 2009 8:19 pm
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
Re: CMake build system for Cthugha *looking for testers*
Posted: Sun Apr 12, 2009 3:53 pm
by sinbad
Wolfmanfx wrote:I like CMake
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
Re: CMake build system for Cthugha *looking for testers*
Posted: Mon Apr 13, 2009 11:46 am
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.
Re: CMake build system for Cthugha *looking for testers*
Posted: Mon Apr 13, 2009 12:32 pm
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.
Re: CMake build system for Cthugha *looking for testers*
Posted: Wed Apr 15, 2009 11:19 am
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
Re: CMake build system for Cthugha *looking for testers*
Posted: Wed Apr 15, 2009 2:53 pm
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
).
Re: CMake build system for Cthugha *looking for testers*
Posted: Wed Apr 15, 2009 4:12 pm
by xadhoom
I fear all samples use the same resources.cfg. No demo sample works if you do not build the ParticleFX plugin.
xad
Re: CMake build system for Cthugha *looking for testers*
Posted: Wed Apr 15, 2009 4:20 pm
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.
Re: CMake build system for Cthugha *looking for testers*
Posted: Wed Apr 15, 2009 10:07 pm
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
Re: CMake build system for Cthugha *looking for testers*
Posted: Wed Apr 15, 2009 10:10 pm
by CABAListic
Hm, you're right. Seems inconsistent to me, though.
Re: CMake build system for Cthugha *looking for testers*
Posted: Fri Apr 17, 2009 10:47 am
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
Re: CMake build system for Cthugha *looking for testers*
Posted: Fri Apr 17, 2009 2:01 pm
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.
Re: CMake build system for Cthugha *looking for testers*
Posted: Fri Apr 17, 2009 2:52 pm
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.
Re: CMake build system for Cthugha *looking for testers*
Posted: Mon Apr 20, 2009 10:08 am
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.
Re: CMake build system for Cthugha *looking for testers*
Posted: Mon Apr 20, 2009 2:23 pm
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.
Re: CMake build system for Cthugha *looking for testers*
Posted: Tue Apr 21, 2009 11:28 am
by Kojack
Not sure about jonim8or's reason, but using Cuda with Ogre requires the render system plugin headers.
Re: CMake build system for Cthugha *looking for testers*
Posted: Tue Apr 21, 2009 2:23 pm
by CABAListic
Alright, I'll put it on my todo, then.
Re: CMake build system for Cthugha *looking for testers*
Posted: Tue Apr 21, 2009 5:39 pm
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
.
Re: CMake build system for Cthugha *looking for testers*
Posted: Fri Apr 24, 2009 7:34 pm
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?
Re: CMake build system for Cthugha *looking for testers*
Posted: Fri Apr 24, 2009 7:39 pm
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"
Re: CMake build system for Cthugha *looking for testers*
Posted: Fri Apr 24, 2009 10:05 pm
by sinbad
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.