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
dermont
Bugbear
Posts: 812
Joined: Thu Dec 09, 2004 2:51 am
x 42

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

Post by dermont »

Couple of minor points regarding the cfg.in templates:

plugins.cfg.in
- the Plugin=Plugin_OctreeSceneManager should be the last entry in the file, otherwise some non PCZ demos crash on start up.
resources.cfg.in
- missing FileSystem=@OGRE_MEDIA_DIR_REL@/PCZAppMedia
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 »

plugins.cfg.in
- the Plugin=Plugin_OctreeSceneManager should be the last entry in the file, otherwise some non PCZ demos crash on start up.
Why is that? That sounds like a bug to me. Plugin load order shouldn't really matter, imho. Or are OctreeSceneManager and PCZSceneManager registering with the same constant? If so, the samples should be updated to create a scene manager by name, not by constant.
dermont
Bugbear
Posts: 812
Joined: Thu Dec 09, 2004 2:51 am
x 42

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

Post by dermont »

I think that it is because both the OctreeSceneManager and PCZSceneManager support all types i.e. have the same sceneTypeMask (0xFFFF). The demos create the sceneManager with something like:

Code: Select all

mSceneMgr = mRoot->createSceneManager(ST_GENERIC, "ExampleSMInstance");
The above "createSceneManager(SceneTypeMask typeMask..." method iterates backwards to find the matching factory registered last based on it's sceneTypeMask. So for non PCZ demos, with plugins.cfg as is, it would still use the PCZSceneManager plugin.

I probably could use the following in the demos to resolve the problem:

Code: Select all

    mSceneMgr = mRoot->createSceneManager("OctreeSceneManager", "ExampleSMInstance");
But if you are not encountering the above problem, it's probably something wrong with my setup.
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 »

Admittedly, I added the PCZ plugins late to the plugins.cfg.in, so I don't really know :) I don't doubt you, though, I merely stated that this is a bug (not in the CMake build system) which should be addressed. We can, of course, change the load order for now.
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 »

It's known. And I guess we have to live with it until Ogre 2. The fix is to comment out the PCZM plugins when not using them, and when you use them, comment out the Octree SM plugin. Works, but it's not elegant. :wink:
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
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 »

The first pass of the CMake build system is in trunk now - thanks to Cabalistic & helpers for such a hugely useful starting point. It was very easy for me to get set up, update for the latest trunk changes and test it out. I'm liking what I see a great deal.

It's in parallel with the existing project files for now, since there are a few things that need sorting out before I'd consider it production ready - CMakeTODO.txt is the reference for that (merged OgreChanges.txt into this). Testers & suggestions continue to be welcome!

I now need to read some CMake documentation so I can understand how this all works :)
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 »

jacmoe wrote:It's known. And I guess we have to live with it until Ogre 2. The fix is to comment out the PCZM plugins when not using them, and when you use them, comment out the Octree SM plugin. Works, but it's not elegant. :wink:
Actually not quite true - placing the OctreeSceneManager at the end is the reliable way to do this. The reason is that the PCZ demo asks for the PCZ SM by name, therefore is capable of resolving the ambiguity over scene type. Other demos are not, so OctreeSceneManager has to be given preference for the general scene types by loading last. Not so much a bug, but a feature of the way the non-PCZ demos select their SceneManager, ie vaguely ;) I've changed the order to fix it, that's how the old system did it.
edolnx
Gnoblar
Posts: 1
Joined: Wed Jan 21, 2009 9:51 pm

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

Post by edolnx »

Do the current CMake files generate MacOS Frameworks? I've been doing a lot of research on them, and it looks like they need to be built manually for now since CMake doesn't have native framework support yet.

That said, I know sinbad was saying he was going to take the torch for MacOS support - but would would you like some help?
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 »

Great :) Just a few quick notes on the CMakeTODO list:
  • Debugging from VStudio might need some "hacks". More specifically, we probably need to specify the working directory via command line switches. It is probably sensible to use the build directory as the debug location, not the install directory, since the .pdb files are not installed. For that matter, it's probably necessary to modify the structure of the build directory and copy the dependencies DLLs to the build directory as well.
  • The dependency DLLs are installed if the according option was selected in CMake.
  • Sample sources are installed and usable if the according option was selected in CMake. I thought about rearranging the samples directory, but it's not actually necessary. Only the Common/bin directory is no longer needed.
  • There is already an (experimental) option to build static Ogre libraries. It is untested, however, and the samples will not work, because the plugin libraries are not yet linked.
  • CMake can generate Code::Blocks project files, and they work, but the Code::Blocks generator is pretty weak in comparison to the Visual Studio one. Basically, the generated project is a "wrapper" around the makefiles. I'm hoping that a future CMake version will improve on this.
  • I have no idea where CMake stands on Mac OSX support. There are options and commands which specifically reference frameworks, on the other hand I see no XCode generator listed in the documentation right now. So Mac support may still be an ongoing process in CMake development.
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 »

sinbad wrote:The first pass of the CMake build system is in trunk now - thanks to Cabalistic & helpers for such a hugely useful starting point. It was very easy for me to get set up, update for the latest trunk changes and test it out. I'm liking what I see a great deal.

It's in parallel with the existing project files for now, since there are a few things that need sorting out before I'd consider it production ready - CMakeTODO.txt is the reference for that (merged OgreChanges.txt into this). Testers & suggestions continue to be welcome!

I now need to read some CMake documentation so I can understand how this all works
If you would like/if it's possible, I could have SVN access in order to maintain the Linux side of things. On the whole, no changes should be needed but frequent checks and changes to ensure it builds will likely be required.
edolnx wrote:Do the current CMake files generate MacOS Frameworks? I've been doing a lot of research on them, and it looks like they need to be built manually for now since CMake doesn't have native framework support yet.

That said, I know sinbad was saying he was going to take the torch for MacOS support - but would would you like some help?
While CMake is largely platform neutral, there are some places that need need Mac specific stuff doing. Unfortunately, I haven't done a single thing to this since I do not have access to a Mac. These places are mostly obvious since there's usually an IF(windows/Unix/macos) bit with the mac block empty.
Framework support will take some testing since that's more a distribution thing than a building thing - but that's what CPack is for I guess.
dermont
Bugbear
Posts: 812
Joined: Thu Dec 09, 2004 2:51 am
x 42

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

Post by dermont »

I'm a bit confused regarding CMAKE, RPATH and installation on Linux:
http://www.k-3d.org/wiki/CMake_and_RPATH

The above link indicates that the RPATH installation is empty, which is the case:

Code: Select all

build directory
--------------------
scanelf --rpath Demo_Grass
 TYPE   RPATH FILE 
ET_EXEC /media/sda2/Development/OGRE/build/ogre-trunk/lib:/usr/local/lib Demo_Grass 

install directory
---------------------
scanelf --rpath Demo_Grass
 TYPE   RPATH FILE 
ET_EXEC   -   Demo_Grass 
It also suggests to either use:
a) the build tree for development / testing - but the Ogre media and config files are set up in the
install directory
b) the really ugly hack of configuring /etc/ld.so.conf or LD_LIBRARY_PATH

So does that mean I have to manually set up the config/media in the build dir to avoid
configuring /etc/ld.so.conf or LD_LIBRARY_PATH or is there some setting I'm missing?
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 »

I was thinking about modifying the build tree to have it use the source tree for media files etc. so that it's usable for development on Ogre itself. However, for your own separate projects using Ogre I do recommend installing Ogre in a common place where its libs can be found. After all, that's the usual situation for any lib and for any of your users, typically.
dermont
Bugbear
Posts: 812
Joined: Thu Dec 09, 2004 2:51 am
x 42

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

Post by dermont »

I was thinking about modifying the build tree to have it use the source tree for media files etc. so that it's usable for development on Ogre itself.
I think that would be a good idea it would mean multiple builds of ogre(e.g threading etc) could share the same media without installing.

Also would it not make sense to install the pkg-config files to the build tree to allow compiling against different versions of Ogre via something like:

Code: Select all

export PKG_CONFIG_PATH=...
LDFLAGS='-Wl,-rpath,/<buildpath>/lib'  ./configure --prefix=<buildpath>
Also the CEGUI-OGRE.pc pkg-config file didn't appear to be installed.
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 »

In my opinion, you should not use the build dir for your project development, it is only meant for developing Ogre itself. For using Ogre, you should really install it because it gives you a clean directory structure. You can easily install multiple versions of Ogre in different locations and you'll get a fitting pkg-config for each. You don't have to install samples and media for each version, either. Besides, what is the point of a pkg-config file in a non-standard location? pkg-config couldn't find it without help, and in that case you could just as well give the directory directly to your project for include and lib search path.

Yes, the CeguiOgreRenderer is missing its pkg-config file, noted.
dermont
Bugbear
Posts: 812
Joined: Thu Dec 09, 2004 2:51 am
x 42

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

Post by dermont »

Ok thanks for the reply. I've found this link which appears to resolve my initial question/problem regarding handling RPATH.
http://www.vtk.org/Wiki/CMake_RPATH_handling
I'm still having problems with loading the OctreeZone/PCZSceneManager plugins, hopefully reading through the CMAKE documentation will resolve the problem.
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 »

edolnx wrote:Do the current CMake files generate MacOS Frameworks? I've been doing a lot of research on them, and it looks like they need to be built manually for now since CMake doesn't have native framework support yet.

That said, I know sinbad was saying he was going to take the torch for MacOS support - but would would you like some help?
Yes, I've been doing some reading and it looks like Mac OSX support is pretty limited - it will generate XCode projects, but there are lots of factors which just aren't covered at all such as universal binaries, frameworks & header visibility etc. I'm sure it's possible to script this somehow, but it seems like it will be more hassle than it's worth. I'm fairly happy keeping the XCode project up to date by hand and usign CMake for everything else, that's still a big improvement over separately managing 3 versions of Visual Studio, 2 versions of Code::Blocks and Linux makefiles as well. But, help is always welcome - although I've learned a lot in the last 18 months I still feel fairly inexperienced in the nuances of the Mac so am always open to suggestions.
CABAListic wrote: Debugging from VStudio might need some "hacks". More specifically, we probably need to specify the working directory via command line switches. It is probably sensible to use the build directory as the debug location, not the install directory, since the .pdb files are not installed. For that matter, it's probably necessary to modify the structure of the build directory and copy the dependencies DLLs to the build directory as well.
Yes, the way I understood it is that the build directory will be for buliding and testing OGRE, so that's where we'll debug our own demos etc. The install directory will be like the SDK structure, and will be used for externally referencing OGRE from other projects. That'll be nice because the same paths can be used when referencing the source release and the SDK, without having to flatten or deepen either of the main source directories.

I think a problem with the working directories is that they're stored in .user files, which CMake doesn't produce. Worst case scenario, we could use template generation to create them? I'm still reading up on CMake so I don't know how to do this yet. I only just figured out where it was getting the "_d" from on debug libraries :)
[*]The dependency DLLs are installed if the according option was selected in CMake.
[*]Sample sources are installed and usable if the according option was selected in CMake. I thought about rearranging the samples directory, but it's not actually necessary. Only the Common/bin directory is no longer needed.
Ah - because of the name I had thought these were part of the 'install' phase rather than the 'build' phase - since in this case that's what we're interested in. In fact for SDK compliance I guess we're interested in both as far as the dependency DLLs are concerned (so there's a consistent place to copy them from).
[*]There is already an (experimental) option to build static Ogre libraries. It is untested, however, and the samples will not work, because the plugin libraries are not yet linked.
Yeah, I found this, and I've removed it from the TODO.

I just thought that I should probably add a 'PlayPen' and 'Tests' option to the TODO too.
[*]CMake can generate Code::Blocks project files, and they work, but the Code::Blocks generator is pretty weak in comparison to the Visual Studio one. Basically, the generated project is a "wrapper" around the makefiles. I'm hoping that a future CMake version will improve on this.
Ah, that's a shame. We'll have to see what C::B users say about this.
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 »

sinbad wrote: I think a problem with the working directories is that they're stored in .user files, which CMake doesn't produce. Worst case scenario, we could use template generation to create them? I'm still reading up on CMake so I don't know how to do this yet. I only just figured out where it was getting the "_d" from on debug libraries :)
It's probably worth googling. After all, we can't be the first ones to want to debug something built with CMake :) Then again, I didn't even try it. Perhaps it's already working in some way?
Ah - because of the name I had thought these were part of the 'install' phase rather than the 'build' phase - since in this case that's what we're interested in. In fact for SDK compliance I guess we're interested in both as far as the dependency DLLs are concerned (so there's a consistent place to copy them from).
Yes, they are part of the install step, I misunderstood you. To make samples work from the build directory, we need to provide a separate set of config files which reference the source dir, plus we need to copy the dependencies DLLs to the build dir. If it's fine with you, I'll tackle the build dir next week (more specifically, Wednesday) and try to get this up and running.
Ah, that's a shame. We'll have to see what C::B users say about this.
Though, I just read some more, we might be able to improve the layout of the CodeBlocks generated project files by adding specific PROJECT commands to each subpart of Ogre. This seems to trigger separate CodeBlocks files, so it might get more close to the structure of the Visual Studio project files. I'll experiment with that.
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 »

CABAListic wrote:
sinbad wrote: I think a problem with the working directories is that they're stored in .user files, which CMake doesn't produce. Worst case scenario, we could use template generation to create them? I'm still reading up on CMake so I don't know how to do this yet. I only just figured out where it was getting the "_d" from on debug libraries :)
It's probably worth googling. After all, we can't be the first ones to want to debug something built with CMake :) Then again, I didn't even try it. Perhaps it's already working in some way?
Nope, the official line from CMake is that these settings are stored in 'proprietary binary files' - which is unfortunately way out of date now (VS hasn't stored working directories in binary .suo files since VS 2003), so it doesn't even try. Googling hasn't brought anything up except posts in mailing lists regurgitating this outdated advice. I think we can do it for VS2005+ with templates at least, but it'll need some work.
Ah - because of the name I had thought these were part of the 'install' phase rather than the 'build' phase - since in this case that's what we're interested in. In fact for SDK compliance I guess we're interested in both as far as the dependency DLLs are concerned (so there's a consistent place to copy them from).
Yes, they are part of the install step, I misunderstood you. To make samples work from the build directory, we need to provide a separate set of config files which reference the source dir, plus we need to copy the dependencies DLLs to the build dir. If it's fine with you, I'll tackle the build dir next week (more specifically, Wednesday) and try to get this up and running.[/quote]

Very much fine with me, I welcome the assistance. Please can you complete a Contributor License Agreement and we can give you commit access to contribute directly to this.
Ah, that's a shame. We'll have to see what C::B users say about this.
Though, I just read some more, we might be able to improve the layout of the CodeBlocks generated project files by adding specific PROJECT commands to each subpart of Ogre. This seems to trigger separate CodeBlocks files, so it might get more close to the structure of the Visual Studio project files. I'll experiment with that.[/quote]

That would be cool :)
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 »

Ok, I wrote another small hack to auto-create vcproj.user files for all targets. Furthermore the build tree now resembles the final install dir in that you will find bin and lib subdirectories as expected. I was able to successfully run a debug session of an Ogre sample from within Visual Studio without any custom configuration necessary. It'll probably need some further testing, but I'm positive it's going to be usable. :)

I sent you a license agreement. I could commit the changes once you've set me up, or I can assemble a patch now.
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 »

Got it, thanks. I've given you commit access, no point you going through the patch process here since this is mostly all your work 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 »

Ok, I committed the changes. This should take care of the source build. However, the build system which is provided for building the samples from an SDK install is not yet updated, in fact I just noticed that it's broken; it gives a weird linking error for all the samples which does not occur in the source build. I'll investigate and fix this (somehow).

I also improved CPack support. CPack will now build a complete nice NSIS installer package with proper license agreement and everything. Only thing it doesn't do is set up the OGRE_HOME environment variable. CPack has no immediate support for such things, but I noticed that there is a possibility to inject custom NSIS commands. It's been a while since I used NSIS, but I'll see what can be done.
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 »

nice to see that there are improvements on cmake :)
have you thought about creating a template CMake file for plugin / 3rd party lib authors, so they could just plug-in their library into the cmake system?
Also, do we have a directory layout (or something like that) for third party libraries that are not in the Ogre SVN itself?

I mean we should have at least a concept ready of how to structure a semi-big project?
atm i use that directory layout:

Code: Select all

*root
**dependencies
***ogre
***caelum
***openal
***...
**main
***source
see yourself: http://rigsofrods.svn.sourceforge.net/v ... endencies/ (note that its a backported cmake buildsystem for ogre 1.4.x)

any better ideas? :)
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 »

Yes, I thought about CMake templates (both for addon libs as well as projects using Ogre), but haven't done any work on it, yet. My priority is to get the system fully functional for Ogre itself, first :)

Anyway, creating a build system structure for a project is the project's concern, imho. We only need to make sure that Ogre's cmake system can be included from a higher-level project.
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 »

CABAListic wrote:Yes, I thought about CMake templates (both for addon libs as well as projects using Ogre), but haven't done any work on it, yet. My priority is to get the system fully functional for Ogre itself, first :)
great :)
i will see if i can find the time to test the whole thing later on :)
CABAListic wrote: Anyway, creating a build system structure for a project is the project's concern, imho. We only need to make sure that Ogre's cmake system can be included from a higher-level project.
sure, but a well known proven layout / cmake variable naming that works without problems with all the ogre3d libs around there would be nice to have ;)
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 »

CABAListic wrote:Ok, I committed the changes.
Awesome, thanks - however I think you forgot to add a file, OgreConfigBuild.cmake? I can't run it here right now.
Locked