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 »

sinbad wrote:
iFire wrote:Both Building From Source and Building with CMake seem to be doing the same role. Can we edit it so that they are united?
Not while the stable version is v1.6, since that doesn't have CMake. Once 1.8 is released we can switch over which is the 'primary' reference and relegate the old Building From Source page to a previous version.
Don't worry - it's being worked on.
The docs are going to be a lot cleaner. :wink:
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
haffax
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4823
Joined: Fri Jun 18, 2004 1:40 pm
Location: Berlin, Germany
x 7
Contact:

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

Post by haffax »

Ogre 1.8? I though it was going to be called 1.7
team-pantheon programmer
creators of Rastullahs Lockenpracht
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 »

haffax wrote:Ogre 1.8? I though it was going to be called 1.7
Confusing, isn't it?
The roadmap says 1.7 for Cthugha. :)
/* 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 »

Well, I committed a couple of changes today. The .lib files are now installed in subfolders according to their build type. RenderSystem headers are installed, and the FindOGRE script has been updated to find them correctly.
Furthermore, the FindOGRE script now pulls in all required dependencies for static Ogre builds so that you can link against that. I've also fixed the CMake project for samples in the installed SDK structures. And, finally, Ogre dependencies can now be installed in the build directory instead of the source directory, if you prefer. Actually, they can go anywhere if you set the environment variable OGRE_DEPENDENCIES_DIR.

Still need to thoroughly test those changes on Linux, though.
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 »

Wouldn't it be nicer to have the dependencies in the build directory by default?
They are build dependent, and I really don't see the point of putting them in the source directory in the first place.
Otherwise: nice changes! :)
/* 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 »

There is no 'default' since you have to choose where to deploy them, anyway. But no, they are not technically build-dependent, but primarily compiler-dependent. If you only work with a single compiler, you'll most likely never need different dependencies, therefore it would be a waste to copy them to all your build directories. But the choice is yours ;) CMake will look at the env OGRE_DEPENDENCIES_DIR first, then in the build dir, then in the source dir.
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:CMake will look at the env OGRE_DEPENDENCIES_DIR first, then in the build dir, then in the source dir.
That's exactly what I meant, great. :)
/* 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 »

jacmoe wrote:
haffax wrote:Ogre 1.8? I though it was going to be called 1.7
Confusing, isn't it?
The roadmap says 1.7 for Cthugha. :)
Yes, I'm a moron and can't keep a track of my own version policy ;)
georgevicbell
Gnoblar
Posts: 3
Joined: Mon Apr 27, 2009 7:46 pm

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

Post by georgevicbell »

Hey, Newbie here...Having a few problems compiling with VStudio 2008 - 64bit...

Got through all the cmake stuff, it was fairly smooth...tried to compile, got an error about adding /bigobj to command line to compile ogremain. Did that, it went away...

Now I am stuck on the dependencies...

I am getting 48 errors looks like all of them are dependency errors - lnk2019: unresolved external symbol FT_DONE_FreeType referenced in function ...

I have put the dependencies in the dependency folder as specified in the docs from the ogre website, and put the folder correctly in cmake, and verified that all the files are correctly referenced in the linker...

I did some more research, found that your supposed to also reference freetype.lib, added that, still does not work...

Some more research and it looks like I may need to be using 64 bit versions of the dependencies?? Just wanted to see if someone has them already made before I get into that...or if people know if that would work...if so, it would be nice if the precompiled assembly page made reference that those assemblies are 32bit only...or had the 64 bit assembiles as well...
User avatar
_tommo_
Gnoll
Posts: 677
Joined: Tue Sep 19, 2006 6:09 pm
x 5
Contact:

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

Post by _tommo_ »

Hi!
I confirm that CMake has heavy problems with the 64 bit versions of VC Studio!

-it can't find directx, even if i have it in my VC shared directories
-it can't find zlib or others even after i edited the additional libs
-OgreMain does not compile because "too many object sectors, use /bigobj"

I am sure that it's an issue of the x64 build because the x86 one built using the same CMake settings without an error. :wink:

PS: does compiling ogre for 64 bit make sense?
OverMindGames Blog
IndieVault.it: Il nuovo portale italiano su Game Dev & Indie Games
georgevicbell
Gnoblar
Posts: 3
Joined: Mon Apr 27, 2009 7:46 pm

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

Post by georgevicbell »

I compiled for x86 VStudio 2008 succesfully. I guess 64bit is still a work in progress...
jonim8or
Goblin
Posts: 287
Joined: Mon Dec 08, 2008 4:49 pm
x 10

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

Post by jonim8or »

I had some trouble with static linking under linux. I got two problems:
1) the zlib and zziplib were linked in wrong order (this is only an issue when linking to static zlib and zziplib)
2) the Xrandr extension functions could not be found.

THe following patch fixed it for me, but I didn't test it on other systems / configurations
I'm also not sure about which paths should be supplied to find Xrandr.

Code: Select all

Index: CMake/Packages/FindOGRE.cmake
===================================================================
--- CMake/Packages/FindOGRE.cmake	(revision 8608)
+++ CMake/Packages/FindOGRE.cmake	(working copy)
@@ -202,6 +202,7 @@
   if (UNIX AND NOT APPLE)
     find_package(X11 QUIET)
     find_library(XAW_LIBRARY NAMES Xaw Xaw7 PATHS ${DEP_LIB_SEARCH_DIR} ${X11_LIB_SEARCH_PATH})
+    find_library(XRANDR_LIBRARY Xrandr PATHS ${DEP_LIB_SEARCH_DIR} )
     if (NOT XAW_LIBRARY OR NOT X11_Xt_FOUND)
       set(X11_FOUND FALSE)
     endif ()
@@ -214,10 +215,9 @@
     endif ()
   endif ()
     
-  
-  set(OGRE_LIBRARIES ${OGRE_LIBRARIES} ${ZLIB_LIBRARIES} ${ZZip_LIBRARIES}
+  set(OGRE_LIBRARIES ${OGRE_LIBRARIES} ${ZZip_LIBRARIES} ${ZLIB_LIBRARIES} 
     ${FreeImage_LIBRARIES} ${FREETYPE_LIBRARIES} 
-    ${X11_LIBRARIES} ${X11_Xt_LIBRARIES} ${XAW_LIBRARY}
+    ${X11_LIBRARIES} ${X11_Xt_LIBRARIES} ${XAW_LIBRARY} ${XRANDR_LIBRARY}
     ${Cocoa_LIBRARIES} ${Carbon_LIBRARIES})
   
   if (NOT ZLIB_FOUND OR NOT ZZip_FOUND)
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 X11 find script normally picks up Xrandr. It's kind of strange that it doesn't for you.
I'll change the link order, thanks. (If I miss one feature of other languages in C++, it certainly is a proper module system. :) )
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 »

@jonim8or: I just checked, the X11 find script already looks for Xrandr and stores it in X11_Xrandr_LIB. I seem to have forgotten to actually include that in the link line (and it mysteriously works for me despite that), but if you could just check if CMake picked up Xrandr in that variable, then I can just use that for the fix instead of looking for Xrandr ourselves.
jonim8or
Goblin
Posts: 287
Joined: Mon Dec 08, 2008 4:49 pm
x 10

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

Post by jonim8or »

You are right, X11 has found it itself. You can just use that.
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 »

When boost isn't found OGRE_USE_BOOST doesn't appear to be set to 0 in buildsettings.h.

Code: Select all

Index: CMake/ConfigureBuild.cmake
===================================================================
--- CMake/ConfigureBuild.cmake	(revision 8639)
+++ CMake/ConfigureBuild.cmake	(working copy)
@@ -36,6 +36,7 @@
 set(OGRE_SET_DISABLE_DDS 0)
 set(OGRE_SET_NEW_COMPILERS 0)
 set(OGRE_STATIC_LIB 0)
+set(OGRE_SET_USE_BOOST 0)
 if (OGRE_CONFIG_DOUBLE)
   set(OGRE_SET_DOUBLE 1)
 endif()
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 »

My bad, fixed, thanks.
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 »

Sorry maybe I didn't explain clearly it should be OGRE_SET_USE_BOOST set to 0 in ConfigureBuild.cmake.

#set(OGRE_USE_BOOST 0)
set(OGRE_SET_USE_BOOST 0)
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 »

You did explain yourself properly, I'm just dumb. :oops:
User avatar
masterfalcon
OGRE Team Member
OGRE Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
x 126
Contact:

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

Post by masterfalcon »

Hello,

I've been working on porting OGRE to the iPhone and while working on the CMake stuff I've run into a couple issues that I hope you guys might be able to shed some insight on.

- Fix linking search paths to include the platform name
- This might require a patched CMake. The $(CONFIGURATION) variable is hard coded into the Xcode generator.
On OS X this is no problem. But with the iPhone SDK you can build for multiple platforms and this requires that
the $(EFFECTIVE_PLATFORM_NAME) variable be appended to linker paths for dependencies. At the moment I'm convinced
that this cannot be done from a CMakefile.

- Can I force it to generate Xcode projects with the 3.1 format so codesigning is supported?
- This might also require some CMake hacking. CMake bug 0008252 includes a patch to fix this.

Any ideas?

David Rogers
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'm sorry, I can't help you here. I own neither a Mac nor an iPhone, so I'm not familiar with either and not with XCode's peculiarities. Somewhere in the CMake documentation or the CMake wiki were some notes about cross-compilation, maybe they could help?
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 »

Heh - I asked him to raise it here because I thought you might have an idea about ways to append the $(EFFECTIVE_PLATFORM_NAME) , since I have a Mac but not so much CMake experience.

I stil have XCode 3.0 but I'll upgrade to 3.1 soon so maybe I can see what you mean. I'm not as much of a Cmake guru as CABAListic but I'll try to help.
User avatar
stealth977
Gnoll
Posts: 638
Joined: Mon Dec 15, 2008 6:14 pm
Location: Istanbul, Turkey
x 42

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

Post by stealth977 »

Is this BOOST issue solved? I cant seem to make it work, CMake cant find boost somehow.

I tried to install it (1.38) using boospro installer to program files, and then tried to install C:\boost etc. no matter what i do, it just cant find boost...Any solutions?

ismail,

Well, this time jacmoe's environment variables solved the problem (it didnt work when boost was installed to d:\, but now it works when i installed to C:\)
Ismail TARIM
Ogitor - Ogre Scene Editor
WWW:http://www.ogitor.org
Repository: https://bitbucket.org/ogitor
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:Heh - I asked him to raise it here because I thought you might have an idea about ways to append the $(EFFECTIVE_PLATFORM_NAME) , since I have a Mac but not so much CMake experience.
The problem is I don't really understand that part. On Linux or Windows I could always manually change the found libs to another platform's SDK, so I don't know exactly why or where this would need to go. And so far I haven't tried to do a cross-platform build with CMake, either, so I don't know what to look out for :)
I do, however, know that in cmake-gui when configuring for the first time there is an extra setting for cross-compilation where you can select the correct tool chain. I do not know if this would help with this specific issue, but I guess you'll need to do that either way.
Is this BOOST issue solved? I cant seem to make it work, CMake cant find boost somehow.
I don't know. It works for me on both Linux and Windows, and the boost find script is still curtesy of CMake, so if it doesn't work for you, I think it would be best if you raised that with the CMake guys.
User avatar
masterfalcon
OGRE Team Member
OGRE Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
x 126
Contact:

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

Post by masterfalcon »

CABAListic wrote:
sinbad wrote:Heh - I asked him to raise it here because I thought you might have an idea about ways to append the $(EFFECTIVE_PLATFORM_NAME) , since I have a Mac but not so much CMake experience.
The problem is I don't really understand that part. On Linux or Windows I could always manually change the found libs to another platform's SDK, so I don't know exactly why or where this would need to go. And so far I haven't tried to do a cross-platform build with CMake, either, so I don't know what to look out for :)
I do, however, know that in cmake-gui when configuring for the first time there is an extra setting for cross-compilation where you can select the correct tool chain. I do not know if this would help with this specific issue, but I guess you'll need to do that either way.

From what I could ascertain from the source code, the Xcode generator in CMake might need to be patched to insert that variable after the $(CONFIGURATION) variable when outputting OTHER_LDFLAGS. $(CONFIGURATION) will be Debug, Release, etc. And with the OS X SDKs that is where the linked products end up but Apple added EFFECTIVE_PLATFORM_NAME to differentiate between device and simulator. So you could have directories with binaries in them named: Debug-iphoneos, Debug-iphonesimulator, Release-iphoneos, Release-iphonesimulator, etc.

So ya. That's all that I've been able to figure out and now I'm stumped with this issue.
Locked