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
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:

Re: CMake build files for Ogre 1.6

Post by CABAListic »

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 :)

CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:

Re: CMake build files for Ogre 1.6

Post by CABAListic »

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?

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 files for Ogre 1.6

Post by jacmoe »

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. :wink:

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.

CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:

Re: CMake build files for Ogre 1.6

Post by CABAListic »

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? :)

CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:

Re: CMake build files for Ogre 1.6

Post by CABAListic »

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 :)

CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:

Re: CMake build files for Ogre 1.6

Post by CABAListic »

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:
  • 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

dermont
Orc Shaman
Posts: 784
Joined: Thu Dec 09, 2004 2:51 am
x 35

Re: CMake build files for Ogre 1.6

Post by dermont »

Nice work, but it appears that some project files are not generated, namely MaterialUpgrader/MeshUpgrader/XMLConvertor/ReferenceAppLayer/BspCollision Demo/PlayPen.

CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:

Re: CMake build files for Ogre 1.6

Post by CABAListic »

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.

User avatar
milliams
Gremlin
Posts: 172
Joined: Fri Feb 16, 2007 1:47 am
Location: Portsmouth, UK
Contact:

Re: CMake build files for Ogre 1.6

Post by milliams »

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?

CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:

Re: CMake build files for Ogre 1.6

Post by CABAListic »

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...

User avatar
milliams
Gremlin
Posts: 172
Joined: Fri Feb 16, 2007 1:47 am
Location: Portsmouth, UK
Contact:

Re: CMake build files for Ogre 1.6

Post by milliams »

[update]
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
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.

CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:

Re: CMake build files for Ogre 1.6

Post by CABAListic »

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.

Mohij
Gnoblar
Posts: 12
Joined: Wed Feb 01, 2006 5:14 pm

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

Post by Mohij »

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:

Code: Select all

-- Looking for FreeImage...
-- checking for module 'freeimage'
--   package 'freeimage' not found
-- Found FreeImage: /usr/lib64/libfreeimage.so
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.
Even a fool is thought wise if he keeps silent, and discerning if he holds his tongue.
Prov17,28

User avatar
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*

Post by milliams »

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?

Mohij
Gnoblar
Posts: 12
Joined: Wed Feb 01, 2006 5:14 pm

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

Post by Mohij »

I used cmake before. And I like it :-)
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

CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:

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

Post by CABAListic »

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.

User avatar
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*

Post by milliams »

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.

CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:

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

Post by CABAListic »

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.

User avatar
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*

Post by milliams »

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.

CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:

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

Post by CABAListic »

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.

User avatar
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*

Post by milliams »

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.
I'm in favour of this rename too. It saves typing and makes things more consistent.
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 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.

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.
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.
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
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:

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

Post by CABAListic »

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.
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.
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 :)

User avatar
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*

Post by milliams »

CABAListic wrote:So I would say let's keep it as it is for now and we can review it later :)
Fine by me :)

Mohij
Gnoblar
Posts: 12
Joined: Wed Feb 01, 2006 5:14 pm

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

Post by Mohij »

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.

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                                                                                           
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.
Even a fool is thought wise if he keeps silent, and discerning if he holds his tongue.
Prov17,28

CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:

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

Post by CABAListic »

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...

Locked