CMake build system for Cthugha *looking for testers*
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: CMake build files for Ogre 1.6
Yeah, though I'm still not completely satisfied with how the package searching works. But the Windows problems are my primary concern right now, I'll think about the rest after that
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: CMake build files for Ogre 1.6
Ok, apparently it has something to do with the subsystem the samples are compiled for. The CMake build files currently set debug builds to SUBSYSTEM:CONSOLE in order to get a console window with the log entries. But all of the samples - except for the two which were working - use WinMain as their main function under Windows, and even though neither compiler nor linker complained, that doesn't seem to work. If I replace WinMain with main, everything's fine, if I instead set the subsystem to WINDOWS, everything's fine, too, except that I lose the console window in debug mode.
I'm a bit confused right now. CMake seems to default to setting debug executables to SUBSYSTEM:CONSOLE, and I was always under the impression that this should work. I need some input from more experienced Visual C++ developers: What is the recommended way to get a console output window in debug builds, but not in release builds?
I'm a bit confused right now. CMake seems to default to setting debug executables to SUBSYSTEM:CONSOLE, and I was always under the impression that this should work. I need some input from more experienced Visual C++ developers: What is the recommended way to get a console output window in debug builds, but not in release builds?
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Re: CMake build files for Ogre 1.6
Look here:
http://www.ogre3d.org/wiki/index.php/Ho ... ug_console
Apparently, merely changing /SUBSYSTEM:CONSOLE to /SUBSYSTEM:CONSOLE /ENTRY:WinMainCRTStartup does the trick. Which is that you can have a console and a WinMain, all at the same time.
I do have a preference for the third alternative, because it does not depend on any project settings, AFAIK.
http://www.ogre3d.org/wiki/index.php/Ho ... ug_console
Apparently, merely changing /SUBSYSTEM:CONSOLE to /SUBSYSTEM:CONSOLE /ENTRY:WinMainCRTStartup does the trick. Which is that you can have a console and a WinMain, all at the same time.
I do have a preference for the third alternative, because it does not depend on any project settings, AFAIK.
/* 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 files for Ogre 1.6
Ah great, that seems to fix it.
Though I just checked the original Ogre VC solutions, and there the subsystem is just set to WINDOWS. Hm, I was under the impression that debug builds of Ogre demos always had the console. Is my memory playing tricks on me here?
Though I just checked the original Ogre VC solutions, and there the subsystem is just set to WINDOWS. Hm, I was under the impression that debug builds of Ogre demos always had the console. Is my memory playing tricks on me here?
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: CMake build files for Ogre 1.6
Ok, I put a lot of work in there today, restructuring the CMake structure a bit to make it cleaner and adding new features, and I think it's really getting there. I'm tired now, but I think tomorrow I can release a major update, and one that finally compiles correctly on Windows, too
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: CMake build files for Ogre 1.6
Ok, here comes the update:
http://downloads.oddbeat.de/ogre.cmake.zip (for Cthugha (trunk))
The system is now actually usable under Windows and can produce a complete SDK installation with the right setup choices. It can install the samples sources alongside with a CMake build script for them. It can also install the dependencies from the dependencies folder. All the samples are working, except for PCZTestApp which complains about a missing media file. Windows should be pretty much covered now, except for CPack support. It should definitely be usable.
The Linux side should also work fairly well. I didn't test as much, but the principal build process works. It worked fine before, anyway, and I think I didn't break anything. As an experiment, I wrote a CMake hack (CMake has currently no support for it, unfortunately) to enable the precompiled header for GCC. Unfortunately, this slightly increased the build time, so I commented it out for now (yes, I'm aware that OgreStableHeaders.h has an #ifdef, I removed that one).
Anyway, a basic build on either Windows or Linux should work fine. So this, I think, is the time for eager testers to give it a try and find all the bugs in the system, especially when modifying the various build configuration options (static build, for example, is completely untested). The zip file contains a document where I started to describe the CMake build system, it provides instructions on how to use them.
As usual, outstanding issues:
http://downloads.oddbeat.de/ogre.cmake.zip (for Cthugha (trunk))
The system is now actually usable under Windows and can produce a complete SDK installation with the right setup choices. It can install the samples sources alongside with a CMake build script for them. It can also install the dependencies from the dependencies folder. All the samples are working, except for PCZTestApp which complains about a missing media file. Windows should be pretty much covered now, except for CPack support. It should definitely be usable.
The Linux side should also work fairly well. I didn't test as much, but the principal build process works. It worked fine before, anyway, and I think I didn't break anything. As an experiment, I wrote a CMake hack (CMake has currently no support for it, unfortunately) to enable the precompiled header for GCC. Unfortunately, this slightly increased the build time, so I commented it out for now (yes, I'm aware that OgreStableHeaders.h has an #ifdef, I removed that one).
Anyway, a basic build on either Windows or Linux should work fine. So this, I think, is the time for eager testers to give it a try and find all the bugs in the system, especially when modifying the various build configuration options (static build, for example, is completely untested). The zip file contains a document where I started to describe the CMake build system, it provides instructions on how to use them.
As usual, outstanding issues:
- DirectX rendersystem failed to compile for me. It complains abount unknown identifiers D3DX_SHADER_OPTIMIZATION_LEVEL or some such. It worked with Shoggoth, I didn't touch that part, so I'm not sure if something changed in trunk and whether it's CMake's fault.
- Had some glibc corruption problems with a quick debug build test under Linux right now. Something to watch out for.
- CPack integration
- OSX support
-
- Bugbear
- Posts: 812
- Joined: Thu Dec 09, 2004 2:51 am
- x 42
Re: CMake build files for Ogre 1.6
Nice work, but it appears that some project files are not generated, namely MaterialUpgrader/MeshUpgrader/XMLConvertor/ReferenceAppLayer/BspCollision Demo/PlayPen.
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: CMake build files for Ogre 1.6
Yes, that's true, those are missing. I left them out for later initially and then forgot, sorry I'll see to them, thanks.
Edit: Updated the ZIP archive. It now contains build directives for the command line tools. PlayPen and RefApp are still missing, though.
Edit: Updated the ZIP archive. It now contains build directives for the command line tools. PlayPen and RefApp are still missing, though.
- milliams
- Gremlin
- Posts: 172
- Joined: Fri Feb 16, 2007 1:47 am
- Location: Portsmouth, UK
- Contact:
Re: CMake build files for Ogre 1.6
Looks good in Linux to me (the build is still running but the cmake step went without problem).
I like the new layout of the CMake related stuff being in one CMake folder.
I guess the Linux PCH stuff you mention came from this CMake bug report? If not, then it may be worth looking at or at least commenting on the bug about your experiences.
I'd second the call for more people to try this out - particularly on Linux since the reason I started my version of the CMake build system is because the autotools version didn't even work. Perhaps updating the first post in the thread or the thread title would help?
I like the new layout of the CMake related stuff being in one CMake folder.
I guess the Linux PCH stuff you mention came from this CMake bug report? If not, then it may be worth looking at or at least commenting on the bug about your experiences.
I'd second the call for more people to try this out - particularly on Linux since the reason I started my version of the CMake build system is because the autotools version didn't even work. Perhaps updating the first post in the thread or the thread title would help?
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: CMake build files for Ogre 1.6
My hack is different than what the cmake modules on that bug report are doing. But ultimately CMake needs native support for precompiled headers because either way is very difficult to do.
But the hack is working, it's compiling the header. The point is just that it slightly increases build time, but that has nothing to do with CMake. Don't ask me why, but I did read that precompiled headers are not guaranteed to lower compile time...
But the hack is working, it's compiling the header. The point is just that it slightly increases build time, but that has nothing to do with CMake. Don't ask me why, but I did read that precompiled headers are not guaranteed to lower compile time...
- milliams
- Gremlin
- Posts: 172
- Joined: Fri Feb 16, 2007 1:47 am
- Location: Portsmouth, UK
- Contact:
Re: CMake build files for Ogre 1.6
[update]
Actually, I am getting a build error in CgProgramManager:
I don't believe I've updated Cg since I last built and I've tried updating to the latest trunk but it didn't help. Is this an Ogre or CMake problem do you think? I'm using Cg 1.5.0014.
Actually, I am getting a build error in CgProgramManager:
Code: Select all
[ 48%] Built target OgreMain
[ 64%] Built target RenderSystem_GL
[ 67%] Built target Plugin_OctreeSceneManager
[ 70%] Built target Plugin_BSPSceneManager
[ 70%] Building CXX object PlugIns/CgProgramManager/CMakeFiles/Plugin_CgProgramManager.dir/src/OgreCgFxScriptLoader.cpp.o
/home/matt/ogre-cmake-trunk/PlugIns/CgProgramManager/src/OgreCgFxScriptLoader.cpp: In constructor ‘Ogre::CgFxScriptLoader::CgSamplerGlobalStateListener::CgSamplerGlobalStateListener(Ogre::CgFxScriptLoader::GlobalStateType)’:
/home/matt/ogre-cmake-trunk/PlugIns/CgProgramManager/src/OgreCgFxScriptLoader.cpp:1046: error: ‘CG_SAMPLER’ was not declared in this scope
make[2]: *** [PlugIns/CgProgramManager/CMakeFiles/Plugin_CgProgramManager.dir/src/OgreCgFxScriptLoader.cpp.o] Error 1
make[1]: *** [PlugIns/CgProgramManager/CMakeFiles/Plugin_CgProgramManager.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 files for Ogre 1.6
No, it's very likely that your Cg version is too old. Assaf Raman added CgFx support to the trunk, I believe that might not be supported below Cg 2.0. (?) In any case, the plugin's building fine for me with Cg 2.1, I highly recommend that version anyway, it fixes at least one annoying bug.
-
- Gnoblar
- Posts: 12
- Joined: Wed Feb 01, 2006 5:14 pm
Re: CMake build system for Cthugha *looking for testers*
I just tried this cmake build system, because the old autotools based system doesn't work when a different ogre version is already installed on the system (it tries to link against this old version instead against the one it builds).
CMake builds and installs flawlessly. Good job *thumbs up*
I encountered two small issues though.
When running CMake it says:
The same thing flickers by when running ccmake.
Samples/Media is not copied over to /usr/local/share/OGRE/media.
Copying files over to there makes it work.
Atm demos segfault when loading OIS, but I guess this has nothing to do with CMake.
I'm on amd64 gentoo.
CMake builds and installs flawlessly. Good job *thumbs up*
I encountered two small issues though.
When running CMake it says:
Code: Select all
-- Looking for FreeImage...
-- checking for module 'freeimage'
-- package 'freeimage' not found
-- Found FreeImage: /usr/lib64/libfreeimage.so
Samples/Media is not copied over to /usr/local/share/OGRE/media.
Copying files over to there makes it work.
Atm demos segfault when loading OIS, but I guess this has nothing to do with CMake.
I'm on amd64 gentoo.
Even a fool is thought wise if he keeps silent, and discerning if he holds his tongue.
Prov17,28
Prov17,28
- milliams
- Gremlin
- Posts: 172
- Joined: Fri Feb 16, 2007 1:47 am
- Location: Portsmouth, UK
- Contact:
Re: CMake build system for Cthugha *looking for testers*
I actually get the same thing. What is happening is that the script (outputs the first of the 4 lines you posted) that searches for freeimage first tries using pkg-config, but it seems that doesn't work for freeimage so it reports failure (the second and third lines). Since pkg-config didn't work, the script goes to the next level where it just tries to search manually in the normal places. Since freeimage is installed to a normal place, it finds it without any trouble (the fourth line). I guess we could just disable the pkg-config step for this package to avoid confusion?
How did you find the cmake system overall? Was the documentation and configuration options sufficient? Or have you used cmake before?
How did you find the cmake system overall? Was the documentation and configuration options sufficient? Or have you used cmake before?
-
- Gnoblar
- Posts: 12
- Joined: Wed Feb 01, 2006 5:14 pm
Re: CMake build system for Cthugha *looking for testers*
I used cmake before. And I like it
I hope it will replace autotools.
I hope it will replace autotools.
Even a fool is thought wise if he keeps silent, and discerning if he holds his tongue.
Prov17,28
Prov17,28
-
- 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*
To have the media files copied, you need to enable the option OGRE_INSTALL_MEDIA in cmake. It's off by default, but it does work for me.
As for pkg-config: Unfortunately, the pkg-config command provides no option to make it silent. I would still leave it in there for completeness. Currently, freeimage does not provide a pkg-config file, but you never know... We could, however, add an info message which states that pkg-config is invoked and the following lines will output pkg-config's results.
As for pkg-config: Unfortunately, the pkg-config command provides no option to make it silent. I would still leave it in there for completeness. Currently, freeimage does not provide a pkg-config file, but you never know... We could, however, add an info message which states that pkg-config is invoked and the following lines will output pkg-config's results.
- milliams
- Gremlin
- Posts: 172
- Joined: Fri Feb 16, 2007 1:47 am
- Location: Portsmouth, UK
- Contact:
Re: CMake build system for Cthugha *looking for testers*
I've just been trying to test the OGRECOnfig.cmake setup and I noticed that we're installing a bunch of Find*.cmake files, included a FindOGRE.cmake file. The purpose of the OGREConfig.cmake file is to make this unnecessary since if anyone does a find_package(OGRE) then cmake will find the OGREConfig.cmake file which will contain all the necessary info.
-
- 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*
Yeah, but the module is a lot more powerful and is also intended to be used by users who want to use CMake for their own projects to build Ogre. The module can do a lot better there because it knows about something as the OGRE_HOME environment variable so that it could find Ogre even if CMake could not find the Config file.
In fact, the module is designed such that it invokes a look for the config file, anyway, so the config file is still used to get information.
In fact, the module is designed such that it invokes a look for the config file, anyway, so the config file is still used to get information.
- milliams
- Gremlin
- Posts: 172
- Joined: Fri Feb 16, 2007 1:47 am
- Location: Portsmouth, UK
- Contact:
Re: CMake build system for Cthugha *looking for testers*
Ok, I suppose the FindOGRE.cmake file makes sense on Windows but on Linux I'd like for the OGREConfig.cmake files to be sufficient (e.g. it makes requiring a certain version of OGRE very easy find_package(OGRE 1.6 REQUIRED)). It should be very easy to add support for finding the extra PCZ etc. stuff to the file so I'll have a look at that.
However, there shouldn't be a problem with CMake finding the OGREConfig.cmake file on Windows since it is installed to C:\Program Files\CMake\OGREConfig.cmake which is in the default CMake search path.
However, there shouldn't be a problem with CMake finding the OGREConfig.cmake file on Windows since it is installed to C:\Program Files\CMake\OGREConfig.cmake which is in the default CMake search path.
-
- 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*
No, it defaults to installing in C:\Program Files\OGRE3D\CMake, which is not in the default path. We could rename everything to OGRE instead of OGRE3D (I'm actually in favour of that, anyway, but will require a global replace, I wasn't in the mood so far), so that it is. But that's still presuming that you don't change the install dir, and the default install location for an SDK package from the website has always been C:\OgreSDK.
It's true that the config versions can supply the version number more easily, something which is usually nearly impossible for the module based version. But I find it in practice not that useful because for most packages you won't have it, anyway, and you also only get it *if* the Ogre version installed was installed with such a config file. On the other hand, the module based version has an easier time finding release and debug builds separately (especially important on Windows) which the configs usually know nothing about.
Which leads to the primary problem: For actually getting to use the config file, a third-party project would have to specifically *not* ship with a FindOGRE.cmake module, because modules take precedence (unless you specifically request a config based find, in which case however the module is completely ignored). However, this is not viable, not anytime soon at least.
I have to say, I am not completely satisfied with the way package finding works with CMake. I feel that it could be vastly improved, especially to make modules and config versions play together much more nicely. But the way it is I feel that overall, a module is more useful and universal and would like to ship a good one with it, one which can internally make use of a config version if a config file is indeed present. I might change my mind if at some time CMake is indeed the primary build system and it is reasonable to suspect an installed config file, or if CMake changes the way it finds packages. But as long as projects have to ship with their own FindOgre module to cover their bases, I don't find the config as useful.
Having said that, we could of course try to get it to determine Ogre's version. CMake has some regex string matching, after all, which should allow for the version to be read from OgreVersion.h (if present) or OgrePrerequisites.h.
PS: If you do want to pursue the config based version, please modify the SET calls in such a way that the include and library search dirs can still be modified in the CMake cache.
It's true that the config versions can supply the version number more easily, something which is usually nearly impossible for the module based version. But I find it in practice not that useful because for most packages you won't have it, anyway, and you also only get it *if* the Ogre version installed was installed with such a config file. On the other hand, the module based version has an easier time finding release and debug builds separately (especially important on Windows) which the configs usually know nothing about.
Which leads to the primary problem: For actually getting to use the config file, a third-party project would have to specifically *not* ship with a FindOGRE.cmake module, because modules take precedence (unless you specifically request a config based find, in which case however the module is completely ignored). However, this is not viable, not anytime soon at least.
I have to say, I am not completely satisfied with the way package finding works with CMake. I feel that it could be vastly improved, especially to make modules and config versions play together much more nicely. But the way it is I feel that overall, a module is more useful and universal and would like to ship a good one with it, one which can internally make use of a config version if a config file is indeed present. I might change my mind if at some time CMake is indeed the primary build system and it is reasonable to suspect an installed config file, or if CMake changes the way it finds packages. But as long as projects have to ship with their own FindOgre module to cover their bases, I don't find the config as useful.
Having said that, we could of course try to get it to determine Ogre's version. CMake has some regex string matching, after all, which should allow for the version to be read from OgreVersion.h (if present) or OgrePrerequisites.h.
PS: If you do want to pursue the config based version, please modify the SET calls in such a way that the include and library search dirs can still be modified in the CMake cache.
- milliams
- Gremlin
- Posts: 172
- Joined: Fri Feb 16, 2007 1:47 am
- Location: Portsmouth, UK
- Contact:
Re: CMake build system for Cthugha *looking for testers*
I'm in favour of this rename too. It saves typing and makes things more consistent.CABAListic wrote:We could rename everything to OGRE instead of OGRE3D (I'm actually in favour of that, anyway, but will require a global replace, I wasn't in the mood so far), so that it is.
The argument for installing a FindOGRE.cmake file is so that a project using cmake as their build system can find OGRE regardless of the build system used to build OGRE. So they would take the FindOGRE.cmake file from OGRE, copy it into their build system and then they would use it to find OGRE. Am I right here? If so, it doesn't really make sense to install it, except maybe as part of the SDK. Either way, I agree it is useful on Windows where people could use it as a template/starting point/complete solution for finding OGRE. However, doing set(${OGRE_DIR} $ENV{OGRE_HOME}/CMake) would also solve the non-standard install location problem since this tells CMake to search this path for the OGREConfig.cmake file.CABAListic wrote:It's true that the config versions can supply the version number more easily, something which is usually nearly impossible for the module based version. But I find it in practice not that useful because for most packages you won't have it, anyway, and you also only get it *if* the Ogre version installed was installed with such a config file. On the other hand, the module based version has an easier time finding release and debug builds separately (especially important on Windows) which the configs usually know nothing about.
Which leads to the primary problem: For actually getting to use the config file, a third-party project would have to specifically *not* ship with a FindOGRE.cmake module, because modules take precedence (unless you specifically request a config based find, in which case however the module is completely ignored). However, this is not viable, not anytime soon at least.
The argument for OGREConfig.cmake is that if a project using cmake as their build system want to find a certain version of OGRE installed using cmake, all they need do is a find_package(). You argue that on Windows this can be difficult due to the likelihood of non-standard install paths and this is true. However, on Linux I think it is the best solution since, for a given install, it gives canonical information.
I agree, keep the FindOGRE.cmake since it's useful in the meantime on Linux and will always have a use on Windows and it looks very thorough.CABAListic wrote:I have to say, I am not completely satisfied with the way package finding works with CMake. I feel that it could be vastly improved, especially to make modules and config versions play together much more nicely. But the way it is I feel that overall, a module is more useful and universal and would like to ship a good one with it, one which can internally make use of a config version if a config file is indeed present. I might change my mind if at some time CMake is indeed the primary build system and it is reasonable to suspect an installed config file, or if CMake changes the way it finds packages. But as long as projects have to ship with their own FindOgre module to cover their bases, I don't find the config as useful.
-
- 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*
Well, in principle you're right, but it's again a problem with the CMake approach. It would be so much more elegant if CMake would look for a config file first and then for a module. Plus the way either works could need an overhaul to simplify their creation and usage.milliams wrote:The argument for installing a FindOGRE.cmake file is so that a project using cmake as their build system can find OGRE regardless of the build system used to build OGRE. So they would take the FindOGRE.cmake file from OGRE, copy it into their build system and then they would use it to find OGRE. Am I right here? If so, it doesn't really make sense to install it, except maybe as part of the SDK. Either way, I agree it is useful on Windows where people could use it as a template/starting point/complete solution for finding OGRE. However, doing set(${OGRE_DIR} $ENV{OGRE_HOME}/CMake) would also solve the non-standard install location problem since this tells CMake to search this path for the OGREConfig.cmake file.
As it is now, I've just made better experiences with module based searches than with the results from a config file (among other things, because most config files don't declare their variables as cache variables and therefore make them inaccessible should you want to link against a different version than the one found).
So I would say let's keep it as it is for now and we can review it later
- milliams
- Gremlin
- Posts: 172
- Joined: Fri Feb 16, 2007 1:47 am
- Location: Portsmouth, UK
- Contact:
Re: CMake build system for Cthugha *looking for testers*
Fine by meCABAListic wrote:So I would say let's keep it as it is for now and we can review it later
-
- Gnoblar
- Posts: 12
- Joined: Wed Feb 01, 2006 5:14 pm
Re: CMake build system for Cthugha *looking for testers*
I got one problem with the include files that cmake copies.
There are include files located in trunk/OgreMain/include and in build/include. In the second directory are only those two files are found: OgreConfig.h OgreVersion.h.
CMake installs the files in OgreMain/include and then replaces the OgreConfig.h and OgreVersion.h with the ones found in build/include.
The samples built by CMake include the only the ones in OgreMain/include (both folders are included, but OgreMain/include later).
The following lines are missing in the build/include version of OgreConfig.h.When the first #ifndef block is missing all Examples segfault.
The final result of this is, that the examples built by cmake work, everything built afterwards which links against the files in /usr/local/include/OGRE segfaults.
The inconsistency that the examples built by cmake include different files than what is later on copied to /usr/local/include/OGRE is definitely a bug.
That the examples segfault without this #ifndef might be a different problem, but if this is generally the case and not only on my machine then those lines should definitely be in there.
There are include files located in trunk/OgreMain/include and in build/include. In the second directory are only those two files are found: OgreConfig.h OgreVersion.h.
CMake installs the files in OgreMain/include and then replaces the OgreConfig.h and OgreVersion.h with the ones found in build/include.
The samples built by CMake include the only the ones in OgreMain/include (both folders are included, but OgreMain/include later).
The following lines are missing in the build/include version of OgreConfig.h.
Code: Select all
// Whether to use the custom memory allocator in STL containers
#ifndef OGRE_CONTAINERS_USE_CUSTOM_MEMORY_ALLOCATOR
# define OGRE_CONTAINERS_USE_CUSTOM_MEMORY_ALLOCATOR 1
#endif
//if you want to make Ogre::String use the custom memory allocator then set:
//#define OGRE_STRING_USE_CUSTOM_MEMORY_ALLOCATOR 1
// Doing this will mean Ogre's strings will not be compatible with std::string however
#ifndef OGRE_STRING_USE_CUSTOM_MEMORY_ALLOCATOR
# define OGRE_STRING_USE_CUSTOM_MEMORY_ALLOCATOR 0
#endif
The final result of this is, that the examples built by cmake work, everything built afterwards which links against the files in /usr/local/include/OGRE segfaults.
The inconsistency that the examples built by cmake include different files than what is later on copied to /usr/local/include/OGRE is definitely a bug.
That the examples segfault without this #ifndef might be a different problem, but if this is generally the case and not only on my machine then those lines should definitely be in there.
Even a fool is thought wise if he keeps silent, and discerning if he holds his tongue.
Prov17,28
Prov17,28
-
- 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*
That problem arises because this is a new commit by sinbad which was not present when I created the OgreConfig.h.in template. The premise is that the source tree of Ogre should no longer contain an OgreConfig.h, because this file is generated as a part of the build configuration process. Since CMake is not currently the official build system, we'll have to update the template whenever something's added to it...