Page 15 of 20

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

Posted: Sat Sep 05, 2009 6:20 am
by jacmoe
So, the morale of this:
Don't install Boost in C:\boost\boost_1_38 - just use C:\boost on Windows. ...

<edit>
I know that this really has nothing to do with Ogre as the find_boost script is shipped with CMake.
</edit>

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

Posted: Sat Sep 05, 2009 7:27 am
by CABAListic
It'd be a good idea to report this to the CMake devs :)

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

Posted: Sat Sep 05, 2009 9:23 am
by jacmoe
Alright. :)
Now something for the Ogre devs ->

In debug mode, the include path to Boost is not set (correctly).
In release mode it's fine: include and linking paths works excellently.
Without me using any environment variable or adding any Boost path to anywhere.
Only using CMake.

But, debug mode is not working that way..
I haven't got as far as to the linking stage, so I don't know if it's library paths as well.
The CMakeCache looks fine.
Must be something specific to debug mode somewhere in the Ogre CMake scripts.
It borks on OgreThreadHeadersBoost.h :(

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

Posted: Sat Sep 05, 2009 9:39 am
by CABAListic
Huh, that sounds suspicious. In CMake, there is no way to define separate include paths for debug and release builds, at least not for Visual Studio. If it really does not set include paths for debug builds while release builds are working fine, then this sounds like a CMake bug... or at least, I don't know what could be wrong in our scripts, right now.

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

Posted: Sat Sep 05, 2009 9:49 am
by jacmoe
I'll triple check my own settings, and go through the Ogre CMake scripts. :wink:
But, yes: it's weird.

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

Posted: Sat Sep 05, 2009 9:52 am
by Klaim
jacmoe wrote:So, the morale of this:
Don't install Boost in C:\boost\boost_1_38 - just use C:\boost on Windows. ...
Are you serious? (not tried Ogre with CMake yet, but following the discussion)

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

Posted: Sat Sep 05, 2009 9:58 am
by jacmoe
I am dead serious. :)
The find_boost script is hard-coded like this:
SET(_boost_INCLUDE_SEARCH_DIRS
C:/boost/include
C:/boost
"$ENV{ProgramFiles}/boost"
/sw/local/include
)
and:
SET(_boost_LIBRARIES_SEARCH_DIRS
C:/boost/lib
C:/boost
"$ENV{ProgramFiles}/boost/boost_${Boost_MAJOR_VERSION}_${Boost_MINOR_VERSION}_${Boost_SUBMINOR_VERSION}/lib"
"$ENV{ProgramFiles}/boost"
/sw/local/lib
)
Notice that you can install it in Program Files as well - but I never install libraries in directories with spaces in their name, just in case..
C:\boost is a safe bet. :wink:

<edit>
Notice the inconsistency:
"$ENV{ProgramFiles}/boost/boost_${Boost_MAJOR_VERSION}_${Boost_MINOR_VERSION}_${Boost_SUBMINOR_VERSION}/lib"
but no C:/boost/boost_${Boost_MAJOR_VERSION}_${Boost_MINOR_VERSION}_${Boost_SUBMINOR_VERSION} check..
Meaning that C:/boost/boost_38_4 will fail..

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

Posted: Sat Sep 05, 2009 10:00 am
by Klaim
O__o

I never installed boost in C:, I have a disk for all my projects and libs, and it's not C: . I know companies where they do the same thing (for some reasons).
It's an issue for me.

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

Posted: Sat Sep 05, 2009 10:02 am
by jacmoe
Luckily, it checks the environment variables too:
BOOST_INCLUDEDIR, BOOST_LIBRARYDIR and BOOST_ROOT :wink:
But that's not setup by the Boost installer.

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

Posted: Sat Sep 05, 2009 10:27 am
by Klaim
Oh ok so it's good to know that you have to set it manually.

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

Posted: Sat Sep 05, 2009 10:44 am
by jacmoe
CABAListic wrote:Huh, that sounds suspicious. In CMake, there is no way to define separate include paths for debug and release builds, at least not for Visual Studio. If it really does not set include paths for debug builds while release builds are working fine, then this sounds like a CMake bug... or at least, I don't know what could be wrong in our scripts, right now.
Sounds suspicious, yes - because it's not true: for some reason I can't build Ogre in either configuration now. :wink:
Doesn't matter if I set the paths or not.
Can't find it.
I used to be able to build Cthugha.. Very strange.

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

Posted: Sat Sep 05, 2009 11:04 am
by jacmoe
I mean: I used to be able to use Cthugha without worrying about Boost in my own projects.
Well, well.. No big deal.
I just thought it was hidden. I'll just use the find_boost script and be done with it.

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

Posted: Sat Sep 05, 2009 1:07 pm
by jacmoe
Btw:
Is it acceptable that each and every thing using Ogre needs to link to the Boost libs?
(..)
Anyone else experiencing this?

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

Posted: Tue Sep 08, 2009 10:04 pm
by haffax
jacmoe wrote:Btw:
Is it acceptable that each and every thing using Ogre needs to link to the Boost libs?
(..)
Anyone else experiencing this?
Here too, it is annoying. But I don't know if this can be circumvented.

What I wondered about right now is that all demos link all the plugins, is this wanted? I can't imagine that this is sensible. I activated the GLES render system to be built but build fails here (missing GLES headers, ok because I don't have them) But also every demo fails to build, because it tries to link to the missing rendersystem.

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

Posted: Tue Sep 08, 2009 10:17 pm
by nbeato
some feedback:

Everything compiled fine on Vista 64 using the DirectX SDK (March 2009) and DirectX SDK (November 2008). However, all of the DirectX linking (d3d9.lib, dx3d9.lib, etc.) assumes that the SDK is in the global library path. CMake finds the lib files and adds them to the projects correctly. However, since the projects don't have "additional library directories" and the "additional input" does not contain the full directory to the lib, the projects fail to link unless you add the DXSDK path to either the projects that require DX or add DXSDK to the global path.

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

Posted: Tue Sep 08, 2009 10:26 pm
by CABAListic
@haffax: Yes, this is wanted, because all of the demos depend on the plugins.cfg file, which is generated according to the plugins you have enabled in your build. If any of those plugins fail to build, the demos won't start unless you manually edit the plugins.cfg. Therefore they do depend on any plugin you are building.
You can of course just disable the GL rendersystem in CMake.

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

Posted: Sat Sep 12, 2009 2:05 pm
by psquare
How can I switch the implemenation to POCO/TBB instead of boost. Similar to BOOST_ROOT I tried setting up POCO_ROOT/TBB_ROOT via the cmake gui, but the libraries are still not found.
Anything obvious I am missing?

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

Posted: Sat Sep 12, 2009 2:13 pm
by CABAListic
First of all, the correct variables are POCO_HOME and TBB_HOME.
TBB is a bit complicated, because TBB by default uses a directory structure for the lib files which is not currently recognised by our find script. You need to copy the library files to POCO_HOME/lib so that the script can pick them up.

Then, once the libs are found, you need to tell CMake to use them instead of boost, because boost is the default implementation. There is a variable OGRE_THREAD_PROVIDER which defaults to boost. Set it to tbb or poco, respectively.

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

Posted: Sat Sep 12, 2009 2:17 pm
by jacmoe
Going to try that. :)
I really hope TBB and POCO are a bit more light weight - at least I hope that you don't have to include and link to them all over the place, like Boost forces you to.

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

Posted: Sat Sep 12, 2009 2:32 pm
by CABAListic
The method of implementation is basically the same. I expect that any problem occuring with boost is likely to occur with the other libs as well.

Specifically, if applications using Ogre are required to link boost-thread, then I suspect that some threading primitives are used directly in Ogre headers. If so, this would need to be changed, otherwise Poco and tbb will require linking, as well.

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

Posted: Sat Sep 12, 2009 2:36 pm
by jacmoe
Just found it a bit excessive that MyGUI, Caelum, whatever, needs to link to Boost, just because they're using Ogre..
They're not anywhere near using the threading Ogre provides.

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

Posted: Sat Sep 12, 2009 4:53 pm
by PaddyWagon
Out of curiosity and because I use a 3rd party library that uses a different version of Boost, are there going to be linkage problems against outside libraries like mine that use more recent Boost distributions?

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

Posted: Wed Sep 16, 2009 7:22 pm
by boyamer
Anyone knows how to setup Cthugha with CMake using Code::Blocks?
I've selected COde::Blocks Ming Make files but i get error on configuration.

Code: Select all

CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.
CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.
CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
Missing variable is:
CMAKE_C_COMPILER_ENV_VAR
CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
Missing variable is:
CMAKE_C_COMPILER
CMake Error: Could not find cmake module file:D:/SVN/Ogre3d trunk/MingW/CMakeFiles/CMakeCCompiler.cmake
CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
Missing variable is:
CMAKE_CXX_COMPILER_ENV_VAR
CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
Missing variable is:
CMAKE_CXX_COMPILER
CMake Error: Could not find cmake module file:D:/SVN/Ogre3d trunk/MingW/CMakeFiles/CMakeCXXCompiler.cmake
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage

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

Posted: Wed Sep 16, 2009 7:39 pm
by jacmoe
Did you install MinGW ?
Is it in C:\MinGW - then you should be all set.

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

Posted: Thu Sep 17, 2009 9:12 am
by boyamer
Well yes,i've installed Code::blocks with MingW?
Or i should install them separated?