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
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 added the test for platform endianess and set the appropriate define in the config file. However, I ignored all the other tests because Ogre does not use HAVE_UNISTD_H or any other of those defines. Furthermore, I renamed config.h to buildsettings.h to avoid potential name conflicts; the Mac port is already using a custom config.h, and if Mac is ever properly supported by CMake, this might have produced some headaches. In the process I also changed the preprocessor define from HAVE_CONFIG_H to HAVE_OGRE_BUILDSETTINGS_H.

Furthermore I configured both the OctreeZone and the PCZTestApp to include the plugins directory in their install RPATH. This should allow to run PCZTestApp directly without any further headaches. However, the PCZ plugins are still troublesome for me, at least on Linux. Some of the samples won't run at all if they are loaded, but those who do produce one of those dreaded "double free or corruption" errors at shutdown. I don't know if PCZ itself is to blame or if the CMake setup for them is flawed somewhere. I need to test with an autotools-built Ogre version (or have someone else confirm it).

Anyway, I also updated the todo list to the current situation. Unless something else pops up, my priority right now is to get packaging support finished via CPack, so that building Ogre SDK packages is as simple as running "make package" or building the PACKAGE target in Visual Studio. CPack is already working in principle and can create various packages, including NSIS installers, but they are still missing some fine-tuning, so that's my focus right now.

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 66
Contact:

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

Post by sinbad »

Awesome, thanks!

davidcb
Gnoblar
Posts: 21
Joined: Wed Sep 17, 2008 1:47 pm

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

Post by davidcb »

I was having slight problems until someone, Sinbad I think, did a commit earlier today. Just finished a debug build. Worked beautifully. Linux Fedora 10.

David.

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 66
Contact:

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

Post by sinbad »

When fixing the Mac build I found a missing endif() in one of the files that I think only the latest version of CMake, released a few days ago, complained about (since I never saw it before). Maybe it was this?

I'm going to try to get CMake working fully on OSX since it doesn't seem as impractical as I first thought. Might take me a while though since using the laptop is no good for my back right now!

davidcb
Gnoblar
Posts: 21
Joined: Wed Sep 17, 2008 1:47 pm

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

Post by davidcb »

Yeah, that was it I think. The error was about an unclosed if in one of the files. It would still allow me to do all the steps but the generated Makefile would not build anything, just exit right away.

David.

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 66
Contact:

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

Post by sinbad »

For info, I'm starting to add CMake files for the Tests & PlayPen.

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, I managed to have the generated NSIS installer set the environment variable OGRE_HOME.

However, I noticed that the PACKAGE step only bundles the current target (debug, release), but never both. I have found no way to generate an NSIS installer which includes both debug and release libs which renders CPack useless for our purposes. It may still provide an elegant way to generate .deb or .rpm packages on Linux, though.

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 66
Contact:

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

Post by sinbad »

Ok, thanks for trying anyway - as you say if it works for Linux targets then it's not useless. We can use the manual SDK generator scripts instead for Windows and OS X - only they'll need to be changed to call cmake instead.

I put the tests & PlayePen into the scripts last night, which was important to me since I use PlayPen a lot!

branan
Gnoblar
Posts: 2
Joined: Mon Mar 09, 2009 5:34 pm

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

Post by branan »

First things first, the new CMake support has cemented my decision to use OGRE for my project.

I'll be embedding OGRE and all dependencies in my build system, like so:

Code: Select all

source
+extern
.+OGRE
.+Freetype
.+zziplib
.+freeimage
.+libpng
.+libmng
.+libtiff
.+libjpeg
.+cegui
.+...
+my_code
This is going to be cross-platform, and I want to make sure there's consistent versioning and build-options for all the prerequisite libraries across multiple platforms, so it's easier just to have all the source bundled in one place.

I'll hopefully have this working properly within a couple of weeks (this is a personal project, so it's not super-high priority). If I need to make any changes to the OGRE CMake support in order to do this, I'll post the patches back here.

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 »

Yes, please do! We certainly want to support embedded building of Ogre, but I've never done anything like that. I believe that the process will work in principle, but you might find that you lack ways to customise the build in ways you might need for such a setup. Therefore your experiences will be very valuable to improve support for that as we finish the CMake build system.

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 66
Contact:

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

Post by sinbad »

I've been wondering about the 3rd-party build too - one issue that I have which perhaps the majority of users don't is that I need to have more than one copy of OGRE installed at any one time. I'll have at least two branches, and sometimes some other custom builds.

FindOGRE.cmake obviously goes looking in the OGRE_HOME, which is fine for most end-users, but in a multi-build environment this isn't going to be enough. Even a branch-specific env variable like OGRE_CTHUGHA_HOME isn't going to be enough if you have multiple builds with different configurations - for example some projects might need a threaded build, some might want double precision, etc. Also, I build with multiple compilers.

Right now, I handle this with relative paths on Windows and OS X, so I'll have multiple checkouts of OGRE and place the external projects relative to the OGRE build I want them to build against. Of course, with CMake I can now have only a single source checkout, and build multiple configurations & with multiple compilers from that one source, which is great - but I have no idea how to handle referencing these separate builds effectively. Even trying to do it with relative paths is difficult since you never know exactly where the build results will go (since that's entirely user configurable).

Is there any precedent for this do you know? Maybe we'd need to allow the user to specify a root directory of the build output they wanted to pull in?

I also have no idea how this would work on Linux. I've always found Linux's insistence on installing libraries in a central location awkward for things like this - at least in Windows and OS X I can put the libraries relative to the EXE so I can control the use of custom builds. In linux it seems like you have to change the name of the library all the time so that alternate builds can exist centrally?

branan
Gnoblar
Posts: 2
Joined: Mon Mar 09, 2009 5:34 pm

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

Post by branan »

If you want a way to find different versions, maybe you should look at FindBoost.cmake, especially BOOST_ROOT.

If you embed OGRE in your own CMake tree, there's no need to use FindOGRE.cmake. You just link against the OgreMain target, and CMake will handle the rest.

EDIT: about linux: This is what soversion is for. Again look in FindBoost for how they handle side-by-side installs of different versions.

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 still preparing the final FindOGRE script, but in principle it will work like this:

First of, the script tries to find Ogre via a config script provided by Ogre itself (this is the OGREConfig.cmake file which gets installed and which is incomplete right now). CMake has a specific order in which it looks for such a config file. It starts by inspecting CMAKE_PREFIX_PATH, this variable can be set on the command line or as an environment variable, perhaps even in the cmake-gui (via "Add Entry", haven't tested this). Then it will look in directories I provide as hints; here I will specifiy the contents of the environment variable OGRE_HOME and also of the CMake variable OGRE_HOME (if it's set). Finally, CMake looks in the path and various other platform-specific locations.
If it does not find a config file (for example, because the Ogre version was built without CMake), then it will do a manual search for the necessary include and library files which has similar orders for lookup. You can read about the details in the CMake help for commands find_package, find_library, find_path.

So, in your case, you could probably set CMAKE_PREFIX_PATH via command line switch to cmake-gui to ensure that the right Ogre version is found. Alternately, if both your standard (i. e. the one that would by default be found, because OGRE_HOME for example points to it) and your desired version provide config scripts, then CMake sets an OGRE_CONFIG_DIR or similar variable to the found config file. You can simply change that variable to use another Ogre build.

Bottom line: I'm not completely sure about all the details of this, but it's certainly going to be possible to switch versions, one way or another. :)

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 just noticed that it's not particularly helpful for the find scripts if static and dynamic libraries are named the same (read: the find modules can't distinguish them). I'm going to add the 'Static' postfix back to the libraries as it was with the old VS static build, at least.

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 66
Contact:

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

Post by sinbad »

branan wrote:EDIT: about linux: This is what soversion is for. Again look in FindBoost for how they handle side-by-side installs of different versions.
That's fine for versions, not so good for alternate builds (double precision, threading, switching between different debug settings in development etc) - unless you uniquely name all of them, which is a pain in the ass really fast. I honestly think having the option to install libraries relatively as well as centrally is a far more flexible setup. The way Windows and OS X will look in the local folder / bundle for libraries is a very useful feature in a lot of very practical situations. .so versioning covers some of the cases, but not all - sure it's fine for stable applications that you install in parallel from fixed public versions, but it's really not so useful for development or custom build deployment where you mess with the builds a lot more. It's a blind spot that I find quite annoying when working with Linux - people try to tell me it's better that way, but I really can't see it unless you only ever deal with version differences, not variable builds.

@CABAListic: ah ok, thanks - I look forward to seeing how it works :) Thanks for the great work as ever.

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

I'll reply to the issue regarding the issue with gcc visibility flags raised here:
http://www.ogre3d.org/forums/viewtopic.php?f=4&t=48545

Here is a link explaining C++ visibility in more detail:
http://gcc.gnu.org/wiki/Visibility

Here is the relevant check from configure.in:

Code: Select all

# Check if compiler supports symbol visibility
# There are quirks for x86_64 and debug builds with gcc < 4.2
AC_LANG_PUSH(C++)
AC_LIBTOOL_COMPILER_OPTION([if $CXX supports -fvisibility],
    [ogre_prog_compiler_supports_visibility],
    [-fvisibility=hidden -fvisibility-inlines-hidden], [],
    [CFLAGS_VISIBILITY="-fvisibility=hidden -fvisibility-inlines-hidden -DOGRE_GCC_VISIBILITY";
    case $target_cpu in
        x86_64* )
            if ! echo "$CFLAGS $CXXFLAGS" | grep -q "\-O"; then
                echo "***********************************************************************"
                echo "WARNING: It looks like you're doing a debug build for an x86_64 target."
                echo "The -fvisibility-inlines-hidden flag is known to give problems in such"
                echo "situations with libstdc++ < 4.2. Disabling the compiler flag."
                echo "***********************************************************************"
                CFLAGS_VISIBILITY="-fvisibility=hidden -DOGRE_GCC_VISIBILITY"
            fi
        ;;
    esac
    case $CXX in
        icpc )
            echo "***********************************************************************"
            echo "WARNING: The intel compiler currently has bugs in its -fvisibility"
            echo "implementation. Disabling the compiler flag."
            echo "***********************************************************************"
            CFLAGS_VISIBILITY=""
        ;;
    esac
    ])
AC_SUBST(CFLAGS_VISIBILITY)
AC_LANG_POP


This is my test for 32 bit machine excluding check for gcc version. Also I seem to recall reading somewhere that the visibility flags should be automatically picked up, but from previous build outputs I didn't see the cxx flags.

Code: Select all

SET(CMAKE_VERBOSE_MAKEFILE ON)
INCLUDE(CheckCXXCompilerFlag)
CHECK_CXX_COMPILER_FLAG(-fvisibility=hidden OGRE_GCC_VISIBILITY)
MESSAGE("Detected gcc4: ${CXX_VERSION}")
SET(CMAKE_CXX_FLAGS "")
if (OGRE_GCC_VISIBILITY ) 
    set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fvisibility=hidden -fvisibility-inlines-hidden")
  ADD_DEFINITIONS(-DOGRE_GCC_VISIBILITY ) 
endif ()

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 »

Great, thanks. I've tried adding it, it does add the -fvisibility flags to the compile options, but so far this results in the compiled Ogre version being unusable. I'll have to investigate what's going wrong.

Edit: Actually it's got nothing to do with the visibility settings. My build is just screwed up in general right now. Damn.

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 »

I haven't run the demos from the build directory so I'm probably wrong but isn't there a typo in InstallResources.cmake, i.e "plugins_d.cfg.in" should be "plugins.cfg.in"

Code: Select all

if (WIN32)
..
else() # other OS only need one cfg file
..
  # create plugins.cfg
  configure_file(${OGRE_TEMPLATES_DIR}/plugins_d.cfg.in ${OGRE_BINARY_DIR}/bin/plugins.cfg)
..

User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
Posts: 3092
Joined: Tue Apr 11, 2006 3:58 pm
Location: TLV, Israel
x 76

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

Post by Assaf Raman »

I have a problem generating the vc8 solution with CMake (BTW: I am using the GUI).
The problem is with the way I use the dependencies - I don't have them in "Ogre/Dependencies" - but in different directories - I get all the dependencies from their SVN\CVS - so my "Ogre/Dependencies" is empty.
I get errors when trying to generate:
The following OPTIONAL packages could NOT be located on your system.
-- Consider installing them to enable more features from this software.
+ boost-thread: Used for threading support <http://boost.org>
+ CEGUI: GUI system used for some of the samples <http://www.cegui.org.uk>
+ OIS: Input library needed for the samples <http://sourceforge.net/projects/wgois>
+ Doxygen: Tool for building API documentation <http://doxygen.org>
+ CppUnit: Library for performing unit tests <http://cppunit.sourceforge.net>
Could not find dependency: OIS
Skipping samples build
The best solution for me will be to change the script of all the "Ogre\CMake\Packages\Find*.cmake" files to search also in an environment variable per dependency - "OIS_HOME", "BOOST_HOME" and such. This wouldn't affect anyone that doesn't use it this way and will really help me.

If a better option exist, how to use it?
If not - do you want to add this change to the scripts or can I?

I am sure I am not the only one that wants to compile the dependencies.
I don't use the dependencies only for OGRE but also for other projects - so I don't like putting them under "Ogre/Dependencies".
Watch out for my OGRE related tweets here.

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 »

You can set the environment variables CMAKE_PREFIX_PATH, CMAKE_LIBRARY_PATH and CMAKE_INCLUDE_PATH. For example you can add all your dependencies' directories to CMAKE_PREFIX_PATH. This should suffice to have CMake find the dependencies there.
But we can certainly add individual environment variables. Actually I think Boost already has one (Boost_ROOT or something like that) as that particular find script is shipped with CMake.

Edit: It might also be possible to add multiple directories to the variable OGRE_DEPENDENCIES_DIR in the CMake GUI. I didn't test it, but a semicolon-separated list of paths might just work.

User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
Posts: 3092
Joined: Tue Apr 11, 2006 3:58 pm
Location: TLV, Israel
x 76

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

Post by Assaf Raman »

Adding individual environment variables is the best option for me - it allows maximum flexibility and allows not to change any of the default CMake options.
Watch out for my OGRE related tweets here.

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 »

Sure, but the CMake variables I mentioned are specifically meant to be modified by a user :)

User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
Posts: 3092
Joined: Tue Apr 11, 2006 3:58 pm
Location: TLV, Israel
x 76

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

Post by Assaf Raman »

I got it, but for me - it will mean changing them by hand each time I re-generate, as an OGRE team member that will happen each time a file is added and I want a "clean" generate.
I what to be able to set the environment variables once - and the generate will use the environment variables.
Watch out for my OGRE related tweets here.

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 »

CMAKE_PREFIX_PATH can be set as an environment variable, as I said - no need to change it every time you rebuild. But I'll add individual ones, if only for completeness and consistency.

User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
Posts: 3092
Joined: Tue Apr 11, 2006 3:58 pm
Location: TLV, Israel
x 76

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

Post by Assaf Raman »

Thanks :D
Watch out for my OGRE related tweets here.

Locked