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 58
Contact:

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

Post by CABAListic »

I don't know, I picked those settings from the old build systems and didn't investigate them any further. Do you have any insights, for what or when these are needed and how we could decide if to include them or not?
User avatar
cdleonard
Goblin
Posts: 266
Joined: Thu May 31, 2007 9:45 am

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

Post by cdleonard »

I finally got around to creating a custom build of ogre using only CMake (on windows). It was really easy to do; except for the inevitably insane compile times. Some feedback:
- Release and RelWithDebInfo overlap both in the build and installed output. It would make sense for each build config to have a directory in output/bin. This wouldn't work with lib files; perhaps lib files could go in output/lib/$config as well?
- Include files used to be in output/include (for a SDK); now they're in output/include/OGRE/. Presumably the structure should be as similar to the current SDK as possible?
- PDB files are not installed. While they're too large for a regular SDK they are very useful in a custom build. This should be an option.
- Plugin headers are no longer installed; not even in include/opt like in the current SDK. The lib files are still there.
- OgreGUIRenderer* is now called CEGUIOgreRenderer*.
- Stuff like resources.cfg is copied to the output by default. Ignoring it is easy enough.

I'm not sure if stuff inside CMAKE_INSTALL_PREFIX is intended to look exactly like an 1.6 sdk; but it's something worth considering.

On a completely unrelated note: CEGUI-OGRE.pc now seems to work in linux.
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 »

@CABAListic,
No insight, just curious, I don't remember -DFREEIMAGE_LIB being included on the old autotools build ( I could be wrong).
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 »

Not too sure if I've missed an update but the CEGUI-OGRE pkconfig file appears to point to non-existant directory. The OgreCEGUI headers appear to be installed in the main Ogre/include dir.

Code: Select all

Cflags: -I${includedir}/OGRE/CEGUIRenderer 
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 58
Contact:

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

Post by CABAListic »

cdleonard wrote:I finally got around to creating a custom build of ogre using only CMake (on windows). It was really easy to do; except for the inevitably insane compile times. Some feedback:
- Release and RelWithDebInfo overlap both in the build and installed output. It would make sense for each build config to have a directory in output/bin. This wouldn't work with lib files; perhaps lib files could go in output/lib/$config as well?
Actually, RelWithDebInfo and MinSizeRel are currently broken on Windows for those reasons. It takes a bit of effort to get all cfg files etc. installed into the correct directories which is way I've done it only for the standard Debug/Release builds so far. I could tell CMake to exclude the rest of the configurations for now; in fact I'm not even sure if RelWithDebInfo does anything useful for MSVC.
- Include files used to be in output/include (for a SDK); now they're in output/include/OGRE/. Presumably the structure should be as similar to the current SDK as possible?
I assume with output you mean installation? It's been a while since I used an SDK, were they really just in include? I think this is not exactly tidy, seeing as how there have to be a couple of dependency headers in there, as well. In any case, I use include/OGRE because this is what Unix needs. I try to keep the platforms in line as much as I can to avoid endless amounts of if cases.

@dermont: Yeah, I intend to change that (i. e. move the include files to that directory), it's more tidy that way.
- PDB files are not installed. While they're too large for a regular SDK they are very useful in a custom build. This should be an option.
CMake does not know about pdb files and offers no option to get at them. It is probably relatively straight-forward to collect them manually, but then again you *can* use the build directory directly without install (at least the CMake FindOGRE script can handle that case) which might be beneficial if you actually want to debug Ogre.
- Plugin headers are no longer installed; not even in include/opt like in the current SDK. The lib files are still there.
Far as I remember plugin headers were never part of the official SDKs. But an according install option is in fact on my todo.
- OgreGUIRenderer* is now called CEGUIOgreRenderer*.
And rightly so! :) If I'm not mistaken, CEGUI calls its renderers CEGUIOpenGLRenderer etc., so CEGUIOgreRenderer fits that scheme, while OgreGUIRenderer doesn't even say it's CEGUI. Besides, it's always been called CEGUIOgreRenderer on Linux builds, so this is another case of getting the platforms in line.
- Stuff like resources.cfg is copied to the output by default. Ignoring it is easy enough.
You mean if samples are not to be installed?
I'm not sure if stuff inside CMAKE_INSTALL_PREFIX is intended to look exactly like an 1.6 sdk; but it's something worth considering.
I'm aiming close, but since it's going to be a new Ogre release I think we can give some rope for a few things. Mostly it is modelled after the old SDKs, though.
User avatar
CrazyEddie
Goblin
Posts: 228
Joined: Thu Feb 12, 2004 10:03 am
Location: Workin' on someting cool
x 1
Contact:

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

Post by CrazyEddie »

CABAListic wrote:
- OgreGUIRenderer* is now called CEGUIOgreRenderer*.
And rightly so! :) If I'm not mistaken, CEGUI calls its renderers CEGUIOpenGLRenderer etc., so CEGUIOgreRenderer fits that scheme, while OgreGUIRenderer doesn't even say it's CEGUI. Besides, it's always been called CEGUIOgreRenderer on Linux builds, so this is another case of getting the platforms in line.
Just popping in here to say that there is/was a disparity between Win32 and other systems as regards to CEGUI renderer naming, however we are also addressing this issue in future releases to unify the naming of modules across all platforms. So this change is, in my opinion, definitely the Right Thing™ to be doing.

CE.
Creator of the CEGUI library.
davidcb
Gnoblar
Posts: 21
Joined: Wed Sep 17, 2008 1:47 pm

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

Post by davidcb »

Hi.

I built Ogre on Linux about a month ago using CMake and everything went smooth.
Tonight I built it and I have a problem with the OpenGL plugin. An undefined symbol, XGetProcAddressARB. I know it is in
OpenGL and I have changed my libraries since last time so I plan to track this down. I just wanted to mention it in case it is
a known issue and not something on my machine.

Also, I have added the OpenGL ES render system to CMake on my machine. So far only tested on linux. Once I get my
problems straightened out here I am going to copy it over to my Windows box and try it there. I don't have a Mac to test on.

Thanks.
David.
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

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

Post by Kojack »

I only skimmed the previous pages and didn't see any mention of this. When I get the latest svn of ogre and use cmake to generate a visual studio 2008 solution, it marks every single header in every project as "exclude from build". Of course that file property only applies to cpps files and is ignored for headers, so everything builds fine, but it means I've got hundreds of red warning icons all over my solution browser.

The absolute file name generation for everything is rather annoying, but I guess I can expand my Ruby script to rip all that out (I already use it to automatically modify ogre's projects to suit my framework's directory structure and make the build neater by isolating most temporary data in a single disposable directory instead of spread throughout the project directories).

Besides that, it works fine so far.
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 »

The "exclude from build" issue probably needs to be raised with the CMake team, this is not our doing.

As for the absolute file name generation: CMake provides an option CMAKE_USE_RELATIVE_PATHS. You could test that one, I think sinbad would be interested in your results, too, as this might be a way to get pregenerated build solutions for the SDK releases, too. Then again, for non-shared project files, what exactly annoys you about the absolute path usage?
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

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

Post by Kojack »

Then again, for non-shared project files, what exactly annoys you about the absolute path usage?
I make multiple copies of ogre when I'm experimenting with stuff in the source, and I carry several solutions around on a portable hard drive so I can work on stuff at home or work, on any of a hundred or so pcs I might end up on that day. Having to regenerate every ogre project file and rebuild the whole thing (and install cmake where ever I am) when all I had to do in the past was press Control-C, Control-V is a bit annoying.
Plus I have both windows xp and vista on my home pc with visual studio, with this I can't build the same solution from both of them, because the drive letters are different.


Looks like the excluded header files problem is fixed in cmake 2.6.4 RC1: http://www.mail-archive.com/cmake@cmake ... 20247.html
But I haven't tested it.

I'll give CMAKE_USE_RELATIVE_PATHS a try, if I can find where to put it. I've never used cmake before this. :)
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

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

Post by Kojack »

I downloaded cmake 2.7 (cvs nightly snapshot) and it fixed the header problem.

I also tried the CMAKE_USE_RELATIVE_PATHS. It makes most things relative (includes, libs, etc) but it leaves pdb files, command and working directory as absolute paths. I built ogre in release, closed it, renamed the base directory, opened it and tried running an app, it wanted to rebuild everything. I renamed the directory back and it ran without rebuild. So it's still absolute path locked even though pdbs aren't built in release mode and command/working dir don't affect builds, just the final runtime. I went through the project files in notepad++ trying to find where else it's doing this, haven't found it yet.

I also noticed that now the ogre resources.cfg file is generated by cmake with absolute paths (even with CMAKE_USE_RELATIVE_PATHS). So not only is the ogre source not relocatable, but even the bin directory is now hard coded to not work if you move it because it can't find the media directory.
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 »

Er, I did download the dependencies - and first I thought I would put them in my new build folder, but I discovered that the CMake scripts had a hardcoded semi-relative path - so this should probably be fixed?
I unzipped the dependencies into ogre_src folder and configured.
Everything was dandy, except for this:
Found CEGUI: optimized;D:/OgreSDK/lib/CEGUIBase.lib;debug;D:/OgreSDK/lib/CEGUIBase_d.lib
Looking for OIS...
Found OIS: optimized;D:/OgreSDK/lib/OIS.lib;debug;D:/OgreSDK/lib/OIS_d.lib
Pretty clever, but that's not what I want. :wink:
I entered the Advanced View and fixed it.
/* 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 58
Contact:

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

Post by CABAListic »

The dependency directory in the source should always take precedence (though I'm going to add a few more spots, I guess). However, if I understood you right, you first put them in the build tree, then run CMake, right? In that case, it didn't find them in the dependencies dir, therefore looked further and found them at the SDK dir. So that's it, the search results are cached, so they won't be researched unless you explicitly reset their values to "NOTFOUND".

@Kojack: Well, I'm sorry, but I guess you've hit the limit of CMake. I see nothing I could do to improve upon that :(
I wonder, though, if you copied your build dir, but would rerun CMake on it, if it would still try to rebuild everything? You probably have to delete CMake's cache (in cmake-gui, it's a menu option) and redo the CMake config, but it might still be an improvement for you, or so I hope.
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 »

CABAListic wrote:The dependency directory in the source should always take precedence (though I'm going to add a few more spots, I guess). However, if I understood you right, you first put them in the build tree, then run CMake, right? In that case, it didn't find them in the dependencies dir, therefore looked further and found them at the SDK dir. So that's it, the search results are cached, so they won't be researched unless you explicitly reset their values to "NOTFOUND".
In my case, CMake found them before I even downloaded the dependencies. :)
I will try again with a totally clean system. :wink:
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

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

Post by Kojack »

Oh well. At least I've already got a Ruby script which will help, I'll just have to use it to post process every ogre project to strip out absolute directories. While I'm at it, I can get rid of one of my pet peeves with 99% of source code these days: intermediate build data being mixed in with projects. I do that to ogre for my own framework already, but I might as well do it for pure ogre solutions too.

Why is cmake so obsessed with hard coding absolute directories everywhere? It even embeds version specific absolute directories of itself (in my case C:\Program Files (x86)\CMake 2.7\bin\cmake.exe) inside of every project as a custom build rule for timestamp checking, installing and packaging. Sounds like upgrading to a new version of cmake without leaving the old one installed would break all existing projects until you re-ran cmake on them.
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 »

Kojack wrote:Why is cmake so obsessed with hard coding absolute directories everywhere? It even embeds version specific absolute directories of itself (in my case C:\Program Files (x86)\CMake 2.7\bin\cmake.exe) inside of every project as a custom build rule for timestamp checking, installing and packaging. Sounds like upgrading to a new version of cmake without leaving the old one installed would break all existing projects until you re-ran cmake on them.
For one thing probably because it is designed under the specific assumption that CMake *is* the build system, and the generated native toolchains are only the means of the build which are generated according to the specific environment. CMake is supposed to deal with differing directory layouts when it comes to dependencies etc., which breaks down again if you share the created native build systems. If you really want to do that, then CMake can't offer any advantage over a native build system in the first place, I guess.
Then, of course, there are paths which cannot be given relatively, particularly when they are on different drives. And since it's more effort to find relative paths it might be that CMake doesn't really bother.
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:

Post by jacmoe »

CABAListic wrote:The FindBoost package is already used, it's implicitly called in the FindDependencies script. If it cannot find boost, I'm afraid you'll have to provide the paths yourself in the CMake configuration.
Used the BoostPro installer. CMake finds BOOST_INCLUDE_DIR, but that's it. I tried to tell it where the threading libs are, but it won't take it. It erases my entry with Boost_THREAD_LIBRARY_DEBUG-NOTFOUND.
I've installed the entire Boost collection of libraries, in all modes, so the libs are definitely there. :wink:
IMO, it should work right out of the box when using the Boost installer. :!:
I changed the default install location of Boost, moved it out from program files/boost to C:/boost - could that be the issue? :)
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
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 »

Other than that: It builds!
I really like this - thanks a lot CABAListic! :)
/* 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 58
Contact:

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

Post by CABAListic »

Hm, I'll look into it. Out of curiosity, since I'm on Linux right now, does the Boost installer set the Boost_ROOT environment variable? Because if not, then yes, changing the default install location may set off the find script - after all, it does not possess psychic abilities :)
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 »

CABAListic wrote:changing the default install location may set off the find script - after all, it does not possess psychic abilities :)
It was psychic enough to know where Boost was installed -> C:\boost\boost_1_38\boost - ie it filled out the BOOST_INCLUDE_DIR var, but failed to find any thread libs. Strange, if you ask me. :)
I can't see any Boost variable - it might be in the registry somewhere, I guess.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
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 in HKLM/SOFTWARE/boostpro.com/1.38/InstallRoot. :wink:
/* 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 58
Contact:

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

Post by CABAListic »

I'll take a look. Though, as I said, the FindBoost script is curtesy of CMake, and I'd like to keep it that way if at all possible. If it doesn't look for the registry values, perhaps I can inject them from the outside...
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 »

I'll try using BOOSTROOT, BOOST_INCLUDEDIR and BOOST_LIBRARYDIR - three environment vars which the CMake FIND_BOOST script checks for.
Strange that it managed to find BOOSTROOT and BOOST_INCLUDEDIR, as I don't see any environment vars in my list. Maybe a reboot is in order?
I'll report back later. :wink:

<edit>
Aw, right: It finds Boost because I moved it to C:\Boost which is a hardcoded possible Boost location in the CMake script.
</edit>
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
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 »

After updating svn it appears that on Linux for a debug build the library names /pkgconfig files are suffixed with "_d", e.g.

Code: Select all

   OGRE_d.pc
   libOgreMain_d.so.1.7.1
I'm assuming the above is to allow side by side installation of release/ debug builds.

How does the above work when building, say for example ogreaddons, projects in debug where the autotool builds are set up to work against the "OGRE.pc" pkgconfig file?

Do I have to update these to specify a debug build option to use "OGRE_d.pc" (yuck)? If so can I just pass debug flags to CXX_FLAGS_RELEASE to replicate a debug build to avoid 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 »

You can manually rename the OGRE_d.pc file, if you want. They are indeed named like that to allow side-by-side installation. Otherwise, yes, you have to update the according projects and no, setting cxx flags won't help because the libraries have a different suffix in debug builds.
Locked