Page 8 of 20

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

Posted: Thu Mar 26, 2009 8:28 pm
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?

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

Posted: Thu Mar 26, 2009 8:36 pm
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.

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

Posted: Thu Mar 26, 2009 8:50 pm
by dermont
@CABAListic,
No insight, just curious, I don't remember -DFREEIMAGE_LIB being included on the old autotools build ( I could be wrong).

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

Posted: Thu Mar 26, 2009 9:01 pm
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 

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

Posted: Thu Mar 26, 2009 9:06 pm
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.

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

Posted: Thu Mar 26, 2009 9:18 pm
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.

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

Posted: Fri Mar 27, 2009 2:45 am
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.

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

Posted: Sat Mar 28, 2009 5:13 am
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.

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

Posted: Sat Mar 28, 2009 8:40 am
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?

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

Posted: Sat Mar 28, 2009 10:16 am
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. :)

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

Posted: Sat Mar 28, 2009 11:38 am
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.

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

Posted: Sat Mar 28, 2009 9:07 pm
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.

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

Posted: Sat Mar 28, 2009 10:28 pm
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.

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

Posted: Sun Mar 29, 2009 12:48 am
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:

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

Posted: Sun Mar 29, 2009 7:09 am
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.

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

Posted: Sun Mar 29, 2009 10:38 am
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.

Re:

Posted: Sun Mar 29, 2009 2:22 pm
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? :)

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

Posted: Sun Mar 29, 2009 2:45 pm
by jacmoe
Other than that: It builds!
I really like this - thanks a lot CABAListic! :)

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

Posted: Sun Mar 29, 2009 2:56 pm
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 :)

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

Posted: Sun Mar 29, 2009 3:00 pm
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.

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

Posted: Sun Mar 29, 2009 3:02 pm
by jacmoe
It's in HKLM/SOFTWARE/boostpro.com/1.38/InstallRoot. :wink:

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

Posted: Sun Mar 29, 2009 3:05 pm
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...

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

Posted: Sun Mar 29, 2009 3:09 pm
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>

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

Posted: Sun Mar 29, 2009 3:25 pm
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?

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

Posted: Sun Mar 29, 2009 3:35 pm
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.