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
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 ran this batch script:

Code: Select all

setx BOOST_ROOT C:\boost\boost_1_38
setx BOOST_LIBRARYDIR C:\boost\boost_1_38\lib
setx BOOST_INCLUDEDIR C:\boost\boost_1_38\boost
And CMake found Boost and the thread library.
Maybe something for the Wiki?

<edit>
I noticed that the CMake find_boost script actually checks for Boost in Program Files - so it will work if we do not change the default Boost installation path. No need to provide the three (optional) environment vars then.
</edit>
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

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

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

Post by dermont »

@CABAListic

Ok thanks for clarification on the debug build. I'm not really interested in side-by-side debug/release installations. I'll try updating the CMake files or fudging the Release build to avoid different suffixes for debug builds.

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 »

@dermont: I'm sorry, but someone else requested it, and I can't satisfy both, or at least not without further effort. Anyway, I think really the external projects should be updated if they really want to link against debug Ogre versions.

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 »

Just a note (something for the Wiki page):
If you want to *build* the INSTALL project, you need to run Visual Studio as Administrator first, if you're on Vista.
It will fail otherwise. Not much different from sudo make install on Linux. :wink:
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

kiske
Greenskin
Posts: 106
Joined: Wed Jul 09, 2003 1:15 pm
Location: Trentino - ITALY
x 1

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

Post by kiske »

Hi,

I'm very new to CMake... but configuring I get this errors:

Code: Select all

CMake Error: File C:/Ogre18/Dependencies/../Samples/Common/bin/debug/CEGUIBase_d.dll does not exist.
CMake Error at Dependencies/CMakeLists.txt:40 (configure_file):
  configure_file Problem configuring file


CMake Error: File C:/Ogre18/Dependencies/../Samples/Common/bin/debug/CEGUIExpatParser_d.dll does not exist.
CMake Error at Dependencies/CMakeLists.txt:41 (configure_file):
  configure_file Problem configuring file


CMake Error: File C:/Ogre18/Dependencies/../Samples/Common/bin/debug/CEGUIFalagardWRBase_d.dll does not exist.
CMake Error at Dependencies/CMakeLists.txt:42 (configure_file):
  configure_file Problem configuring file


CMake Error: File C:/Ogre18/Dependencies/../Samples/Common/bin/release/CEGUIBase.dll does not exist.
CMake Error at Dependencies/CMakeLists.txt:46 (configure_file):
  configure_file Problem configuring file


CMake Error: File C:/Ogre18/Dependencies/../Samples/Common/bin/release/CEGUIExpatParser.dll does not exist.
CMake Error at Dependencies/CMakeLists.txt:47 (configure_file):
  configure_file Problem configuring file


CMake Error: File C:/Ogre18/Dependencies/../Samples/Common/bin/release/CEGUIFalagardWRBase.dll does not exist.
CMake Error at Dependencies/CMakeLists.txt:48 (configure_file):
  configure_file Problem configuring file


CMake Error: File C:/Ogre18/Dependencies/../Samples/Common/bin/release/cg.dll does not exist.
CMake Error at Dependencies/CMakeLists.txt:49 (configure_file):
  configure_file Problem configuring file


CMake Error: File C:/Ogre18/Dependencies/../Samples/Common/bin/release/OIS.dll does not exist.
CMake Error at Dependencies/CMakeLists.txt:50 (configure_file):
  configure_file Problem configuring file
I've just updated the from the tronk this morning.
the dependencies that tells are missing are currently located in c:\ogre18\Dependencies\lib\debug or release...
Where should I look?
<Kiske>

Well can you blame us? For living our dreams...
- Twisted Sister -

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 »

Hm, that particular section assumes that you unzipped a prebuilt Dependencies package from the Ogre website to your Ogre source directory. I guess I need to make that section smarter...

kiske
Greenskin
Posts: 106
Joined: Wed Jul 09, 2003 1:15 pm
Location: Trentino - ITALY
x 1

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

Post by kiske »

CABAListic wrote:Hm, that particular section assumes that you unzipped a prebuilt Dependencies package from the Ogre website to your Ogre source directory. I guess I need to make that section smarter...
In fact I unzipped the prebuilt dependencies package as you said....
So, in the meantime the section becomes smarter, what could I do to compile?

Thanks in advance...
<Kiske>

Well can you blame us? For living our dreams...
- Twisted Sister -

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 »

Which dependency package did you use? Normally they should contain a Samples folder which includes the files CMake is complaining about.
If those DLLs are actually in Dependencies/lib, you could move them for now.

kiske
Greenskin
Posts: 106
Joined: Wed Jul 09, 2003 1:15 pm
Location: Trentino - ITALY
x 1

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

Post by kiske »

Ok, it works, I've just re-downloaded the dependencies package... it seems just strange, because it SHOULD be the same I used the last time... But nevermind, it now works and that's good enough... :D

Thanks!
<Kiske>

Well can you blame us? For living our dreams...
- Twisted Sister -

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 65
Contact:

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

Post by sinbad »

jacmoe wrote:Just a note (something for the Wiki page):
If you want to *build* the INSTALL project, you need to run Visual Studio as Administrator first, if you're on Vista.
It will fail otherwise. Not much different from sudo make install on Linux. :wink:
You might be able to avoid this by changing the install location. I personally set mine to a a subfolder of the build location (I might make this the default, I think it makes more sense).

AFAIK MSVC on Vista is still a total pain in the ass if you don't run it as Administrator - I don't think MSVC 2005 is even supported in any other mode (and it still caused me problems at times). This is one reason why I prefer not to touch Vista with a barge pole if I can help it (also that it devours more of my precious memory for no good reason). A shoddy, shoddy OS that I regret having bought (twice!).

On a lighter note, OS X is almost there with CMake now. I have everything building, but nothing will actually run properly yet. Currently CMake is making the samples reference the framework directly from the build location, and I need to replicate the setup we had before where it's amenable to .app bundling (OS X application installs should be drag-drop), and will work in deployed environments. Previously I symlinked to replicate this without duplication of libraries, I'm experimenting for now to see if I can do it another way while still proving that standalone bundling will work.

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 »

sinbad wrote:
jacmoe wrote:Just a note (something for the Wiki page):
If you want to *build* the INSTALL project, you need to run Visual Studio as Administrator first, if you're on Vista.
It will fail otherwise. Not much different from sudo make install on Linux. :wink:
You might be able to avoid this by changing the install location. I personally set mine to a a subfolder of the build location (I might make this the default, I think it makes more sense).
Yes, that would be neater.
And then we just prevented a flood of Help, can't install Ogre questions.. :)
/* 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: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 65
Contact:

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

Post by sinbad »

I figured out how to do that, so now it defaults to the sdk/ subfolder of the build location on Windows and Mac - that's basically what it's for there anyway. You will have to delete your cache to see this happen, since it still respects settings you pick yourself too.

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 65
Contact:

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

Post by sinbad »

I've added the OGRE_STANDALONE_BUILD option - this makes CMake generate relative paths and also removes the ZERO_CHECK so that the resulting projects do not try to run CMake if they think the CMakeLists have been updated. This means we should be able to distribute a source release which is pre-configured with the basic settings and will build without CMake available. I would use it in my source packaging script for example.

Can someone try this option on Linux please?

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 »

I'm a bit preoccupied this week (actually till April 14th), but I'll take a look once I find a quiet minute :)

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 65
Contact:

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

Post by sinbad »

Ok :) For the record, it doesn't work on OS X - using the option results in a failed build because the XCode project still tries to execute the 'CMakeReRun' script, which doesn't exist.

It's not the default anyway, so even if it works in some cases (seems fine in MSVC) then it's useful. I'd just be interested to know later if it's worth doing for a Linux source release.

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 »

Well, it does seem to skip some steps in the generated Makefiles, but it still references CMake and reacts to modifications of the CMake files. I didn't test if it's actually possible to move the build tree (i. e. whether relative paths work).
In any case, since CMake replaces configure, pure Makefiles are not that relevant for Linux, anyway.

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 65
Contact:

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

Post by sinbad »

Ok, I'll leave the option in there purely for generating stand-alone Windows source releases. It's almost always Windows users that whine about having to download extra tools anyway ;)

I finally got the CMake build working on OS X! Demos are running, it's looking good. I had to change the way a few things work, such as using dylibs for plugins and assuming that PPC support will be done via a separate build directory and not via universals (in practice I see little merit in universal binaries anymore, why double your application size when you can provide a separate PPC version for the minority still using them?) but I think we're there. :D There's a bit of tidying up to do but it's now the primary system on OS X too.

The only issue with it is that only the Debug and Release builds are supported, because many of the CMake scripts assume only 2 possible output folders. I wondered why this was? Actually the RelWithDebInfo in particular is useful as a build, particularly for remote diagnostics. Was there a particular reason why the scripts assume only those 2 configurations?

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 »

Well, basically I started with them because those were the two options the original VS solutions provided. Since each configuration requires some extra ifs in the CMake files, I guess I was just too lazy to add them later on. I'm not even sure if RelWithDebInfo works with VS (as in: produces something that actually matches the name), and so far VS was the only one which could use multiple build targets.
In summary: No particular reason. If RelWithDebInfo has merit with XCode, then sure, we can add it.

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 65
Contact:

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

Post by sinbad »

The equivalent of what I would expect RelWithDebInfo to do is definitely something I used in VS - actually the 'Release' build in the old projects by default included debug information, since it takes up next to no space in the DLLs themselves, it's all in the PDBs - you then keep the PDBs while sending out the DLLs, and can examine crash dumps from the wild much more effectively. I don't know if gcc has an equivalent, I assume so.

Maybe that's actually the more practical option, making CMake generate debug information in Release mode by default. Worth experimenting with...

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 »

Ok, in that case it's certainly worth adding support for RelWithDebInfo (and for MinSizeRel, just for completeness).
Yes, gcc can add debug information to release builds, no problem. I've actually chosen RelWithDebInfo to be the default for Linux builds. (the Makefile builds are generated for one particular build type, so here RelWithDebInfo is working, anyway.)

mysterycoder
Google Summer of Code Student
Google Summer of Code Student
Posts: 169
Joined: Sat Dec 03, 2005 2:04 am
x 6

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

Post by mysterycoder »

I haven't built Ogre with CMake yet, but I was working on my own CMake files for another project and wanted to let you know about a problem you might encounter on linux (I apologize if this has already been brought up before).

While the FindBoost.cmake script generally works fine on linux, there is a problem with using a non-standard installation prefix such as /usr/local/. Even if you set BOOST_ROOT or another variable like BOOST_INCLUDEDIR in the cmake script, the FindBoost.cmake will always first find the version of boost that is installed in the standard location (in /usr). This can be a problem for people working on systems with an already existing boost installation, but who wish to compile Ogre against their own, more recent build of Boost.

The bug is documented here (Issue 1).
My Google summer of code 2011 topic: Dual Quaternion Skinning
My Google summer of code thread
My Google summer of code wiki page

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 »

Judging from the comments the issue has been resolved in CMake (cvs at least). Which is good, because FindBoost is a rather complex module which I would rather not want to make a modified copy of for Ogre.

mysterycoder
Google Summer of Code Student
Google Summer of Code Student
Posts: 169
Joined: Sat Dec 03, 2005 2:04 am
x 6

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

Post by mysterycoder »

Unfortunately I don't think that is the case. Originally I arrived at the same conclusion, but I tried it myself with the cvs version, and it still isn't fixed. I think that only the second issue in the bug was fixed, which is why it is still open.

Based on the comments made in the bug and at looking at it myself, I think the problem stems from how they searching for the headers and libraries.

Code: Select all

# Look for a standard boost header file.
FIND_PATH(Boost_INCLUDE_DIR
   NAMES         boost/config.hpp
   HINTS         ${_boost_INCLUDE_SEARCH_DIRS}
   PATH_SUFFIXES ${_boost_PATH_SUFFIXES}
)
${_boost_INCLUDE_SEARCH_DIRS} is a list of the search directories to go through, and BOOST_ROOT is added to it if it is defined or is an environment variable. However, ${_boost_INCLUDE_SEARCH_DIRS} is only passed in as a HINT to FIND_PATH, so the default path (/usr/) is searched through and found first.

After fiddling for a bit I found that if I pass NO_DEFAULT_PATH to FIND_PATH, it finds them correctly, though I'm not sure about how to do a permanent fix.
My Google summer of code 2011 topic: Dual Quaternion Skinning
My Google summer of code thread
My Google summer of code wiki page

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 »

By calling FIND_PATH twice - first time with NO_DEFAULT_PATH, second time without (plus for the second time you can omit the hints). If the first run finds something, then the second one will do nothing.

Still, I'd rather leave that bug to CMake. If this works, please report it there.

mysterycoder
Google Summer of Code Student
Google Summer of Code Student
Posts: 169
Joined: Sat Dec 03, 2005 2:04 am
x 6

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

Post by mysterycoder »

Oh shoot!
This is really is not a bug, the problem is that you have to define BOOST_ROOT before you include(FindBoost), not just before you call find_package.
Upon further examination of the CMake documentation, FIND_PATH searches the HINTS before it searches system-defined paths.

Sorry for wasting your time. :oops:
My Google summer of code 2011 topic: Dual Quaternion Skinning
My Google summer of code thread
My Google summer of code wiki page

Locked