Page 11 of 20

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

Posted: Fri Apr 24, 2009 11:18 pm
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:

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

Posted: Fri Apr 24, 2009 11:44 pm
by haffax
Ogre 1.8? I though it was going to be called 1.7

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

Posted: Sat Apr 25, 2009 12:08 am
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. :)

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

Posted: Sat Apr 25, 2009 1:05 am
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.

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

Posted: Sat Apr 25, 2009 1:15 am
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! :)

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

Posted: Sat Apr 25, 2009 1:52 am
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.

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

Posted: Sat Apr 25, 2009 2:02 am
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. :)

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

Posted: Sat Apr 25, 2009 3:23 pm
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 ;)

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

Posted: Tue Apr 28, 2009 11:33 pm
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...

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

Posted: Sun May 10, 2009 6:19 pm
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?

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

Posted: Mon May 11, 2009 4:26 pm
by georgevicbell
I compiled for x86 VStudio 2008 succesfully. I guess 64bit is still a work in progress...

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

Posted: Wed May 20, 2009 11:15 am
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)

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

Posted: Wed May 20, 2009 11:46 am
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. :) )

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

Posted: Wed May 20, 2009 7:20 pm
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.

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

Posted: Mon May 25, 2009 9:16 am
by jonim8or
You are right, X11 has found it itself. You can just use that.

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

Posted: Fri May 29, 2009 4:05 am
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()

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

Posted: Fri May 29, 2009 5:26 pm
by sinbad
My bad, fixed, thanks.

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

Posted: Sat May 30, 2009 5:21 am
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)

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

Posted: Sat May 30, 2009 11:19 am
by sinbad
You did explain yourself properly, I'm just dumb. :oops:

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

Posted: Tue Jun 09, 2009 7:46 am
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

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

Posted: Tue Jun 09, 2009 8:55 am
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?

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

Posted: Tue Jun 09, 2009 11:00 am
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.

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

Posted: Tue Jun 09, 2009 11:27 am
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:\)

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

Posted: Tue Jun 09, 2009 12:41 pm
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.

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

Posted: Tue Jun 09, 2009 2:27 pm
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.