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

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

Post by CABAListic »

Gah, sorry, you're right. Slipped my mind I had created that file. It's committed now :)
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 »

Hm, I discovered why the installed samples sources would not build. Visual Studio actually compiles against the default OgreConfig.h included in the OgreMain/include dir instead of the auto-generated OgreConfig.h in the build dir, even though the latter is defined as the very first include directory in the CMake system. Therefore, the final OgreConfig.h installed in the install dir (which is the auto-generated one) may be different from the default one, making the header incompatible with the built libraries.
The right way would be to delete the default OgreConfig.h, but this is not possible as long as we keep *any* other build system around (and we will be keeping XCode at least, the way it looks). Therefore, we need to enforce that Visual Studio takes the right OgreConfig.h.

I see three ways to do that:
  • OgreConfig.h is only included by OgrePlatform.h, as far as I can see. The easiest fix is to change

    Code: Select all

    #include "OgreConfig.h"
    into

    Code: Select all

    #include <OgreConfig.h>
    That way Visual Studio will stop preferring the current dir over the list of supplied include directories and therefore pick up the auto-generated OgreConfig.h. It does break style, though, and may cause problems if someone in his project includes via OGRE/OgreSomeHeader.h.
  • The second way is to have the CMake build system provide a preprocessor define, something like OGRE_CMAKE_BUILD. Then it will create a file OgreGeneratedConfig.h in the build dir instead of OgreConfig.h. The default OgreConfig.h can now be modified in this way:

    Code: Select all

    #ifdef OGRE_CMAKE_BUILD
      #include "OgreGeneratedConfig.h"
    #elif
      // previous contents from OgreConfig.h
    #endif
    
    This way, in case of the CMake build it will simply act as a wrapper for the correct auto-generated config file. Of course, OgreGeneratedConfig.h is the one which gets installed as the final OgreConfig.h in the install dir, so the wrapper is only needed during the original build.
  • The potentially cleanest way is to isolate the default OgreConfig.h in its own directory. CMake would simply ignore that directory, any other build system could add it to its include dir list. However, this requires modification of all other build systems for the time being.
Thoughts?
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 »

Oh, this reminds me that I wanted to talk to you about the OgreConfig.h template anyway.

Do we really need to do this? Ideally, all the settings in OgreConfig.h should be guarded by #ifndef OGRE_WHATEVER so that if a precompiler setting is set elsewhere - either through the command line, or the inclusion of some other header before it, that the values in OgreConfig.h are overridden. Is there a specific reason a config file is generated rather than just adding -D etc to the build command?

We are not going to be able to remove OgreConfig.h anyway since the OS X support on CMake is not good enough, so manual XCode projects will remain. So really, I'd prefer to keep a single copy of OgreConfig.h as it currently is. As a fallback, the #ifdef OGRE_CMAKE_BUILD option seems reasonable - although again the rest of OgreConfig.h shouldn't need to be in the #else so long as they are all guarded by their own #ifdefs (which if they're not, they should be).
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 »

Hm, you mean we should override the OgreConfig.h settings for the build via CMake? Then we would need the generated OgreConfig.h only for the install directory so that projects linking with Ogre get the right settings. Yes, that's certainly doable. I'll make the adjustments. :)
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 »

Alright, it's done. The build now makes use of preprocessor defines given to the compiler, OgreConfig.h remains untouched. Furthermore, I've taken a slightly different route to creating the final OgreConfig.h (the version which gets installed) by taking the original OgreConfig.h and modifying its contents as necessary. This ensures that any changes made to that file are carried along.

The next steps I'm planning include getting rid of the Ogre version information in the CMake system. Instead I intend to have CMake read the Ogre version from the header file. That will eliminate another source of redundant house-keeping. After that I want to improve the FindOGRE and OGREConfig scripts so that they provide a lot more useful information about the installation of Ogre found to projects using CMake. And when that's done, I suppose I finally have to actually test a static build (which I've avoided so far).

One question, though: In the TODO list, you listed "establish 3rd-party library build procedure" as an essential requirement. What exactly does this mean?
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

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

Post by Noman »

The common solution for this option is to have a preprocessor option called "USE_CONFIG_H", and then, naturally, guard all of OgreConfig.h's contents with it.

It's pretty common in the linux projects...
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 »

Yes, but any project using Ogre would have to define that, otherwise they would get linking errors. I think the current solution works better (unless I missed something).
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 »

After some more thought I decided to go with the config.h route. It makes the CMake code cleaner and less error-prone. During Ogre build, HAVE_CONFIG_H is defined by the CMake system, furthermore the installed version of the OgreConfig.h file will simply begin with the added line #define HAVE_CONFIG_H.
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 »

Thanks for all the great updates.

Of course, I'm an idiot - the need to have all the build options encoded in the file is for external projects referencing it. Doh!

I like the HAVE_CONFIG_H style but I think we should make it OGRE-specific, like OGRE_USER_CONFIG_H, otherwise there's a danger this may be defined by an external project.

The "Establish 3rd-party library build procedure" option was about creating some documentation about how external projects should reference OGRE, when using CMake and when not. Basically I want it to be easy for people to switch over their projects from the old way to the new way. I realise it can't be universal because the person building it could pick anywhere to put the build / install results, but a general guide such as telling people to run the install build and reference files from there etc. This is probably a wiki article.

I've updated the samples projects so that they have manual depdencies added for the plugins. This is because in development, I'll often just build one sample and fire it up, and before, the plugins would not necessarily get (re)built which could cause problems.

Removing the duplication of the version info sounds great - it's definitely important to remove all the duplication we can (after all, that's why we're using CMake :)). Again, thanks for all the work on this.
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 »

Ah right, I misinterpreted "3rd-party library", I thought you might be referring to a way to be able to build the dependencies along the way (which would be possible, but quite a lot of added effort) :) Yes, I will certainly write some documentation and possibly sample CMake projects once the system is done and fully approved. Right now, I still have work to do on the OGREConfig.cmake and FindOGRE.cmake scripts which are necessary (or at least highly useful) for external projects to use Ogre via CMake.

As for HAVE_CONFIG_H: I actually used that because it was already present. I think the autotools build already uses it. But I suppose I could use a different define for CMake.

As for the sample dependencies: Good idea, but ultimately I think it is more elegant to specify "minimal" dependencies for each sample. I. e. only the plugin the specific demo needs plus any rendersystem. In the same way, any demo which depends on a plugin not being built should be excluded from the build altogether. But that's some tweaking for later on :)
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 »

CABAListic wrote:As for the sample dependencies: Good idea, but ultimately I think it is more elegant to specify "minimal" dependencies for each sample. I. e. only the plugin the specific demo needs plus any rendersystem. In the same way, any demo which depends on a plugin not being built should be excluded from the build altogether. But that's some tweaking for later on :)
Sorry, I have to disagree here - during development, you really just want to hit F5 and be able to debug directly. Without these dependencies, what actually happens is a runtime error, since the plugins are either not there, or they're built against older versions (if I've just changed the OgreMain interface for example). Having to manually batch build in this case is total PITA, particularly for me and other core devs (maybe not so much for external projects since they'll just batch build everything once only).

When it comes down to it, all the plugins actually *are* dependencies of the samples, because they will not run without all the plugins being built by nature of the way the samples are configured (since they all share a plugins.cfg). They're just runtime dependencies rather than compile/link time dependencies. Yes, you could take the purist view but in actual fact if you don't put these dependencies in there and just build a single sample, the build is actually invalid as a whole, you just won't know it until you try to run a sample.
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 »

You're right, I forgot about the plugins.cfg. Yes, that effectively makes all built plugins a dependency.
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 »

On another note, I just tested a static build with CMake. The good news is that everything built without error, the bad news is that nothing runs (at least the samples don't, I don't have a project prepared to link against a static Ogre version). Of course, I absolutely expected that, I don't even know if the samples can even be linked statically due to plugin management. But the error I got surprised me because it was complaining about missing resource files for ConfigDialog. Does this mean that any project wishing to use ConfigDialog (including the samples) would have to include the OgreMain resource files?
Aside from that, anything else I should be aware of for a correct and usable static build? I haven't investigated any further yet.
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 »

Yeah, the only demo that actually tested the static build was PlayPen, which includes a helper class for loading plugins statically: StaticPluginLoader.h . I guess we could promote this code to 'ExampleStaticPluginLoader.h' or something like that and use it in the main demos.

Which reminds me, another thing for the TODO is to allow the inclusion of test builds, or create another project with the tests in them. Yeah, actually the latter would probably be better. These would never get installed and so you'd want to keep them out of OGRE.sln et al.
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 »

You mean the projects inside Tests? We can fine-tune what gets built and what gets installed. We could simply provide another option (default off) to build the tests, if selected they would appear in OGRE.sln and could be built there, but still not installed. Another project is also doable, but we would have to include CMake code to find the built Ogre libraries.
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 »

I'm still unsure how the PCZSceneManager/ PCZTestApp is meant to run on Linux from
either the install dir/after installation.

With the normal autotools build rpath is embeded in the PCZTestApp and OctreeZone plugin so that it can find libPlugin_PCZSceneManager.so, e.g:

Code: Select all

scanelf -r /usr/local/lib/OGRE/Plugin_OctreeZone.so
TYPE   RPATH FILE 
ET_DYN /usr/local/lib/OGRE /usr/local/lib/OGRE/Plugin_OctreeZone.so 

scanelf -r PCZTestApp
TYPE   RPATH FILE 
ET_EXEC /usr/local/lib/OGRE PCZTestApp 
From the cmake install dir this doesn't appear to be the case.

Code: Select all

scanelf -r Plugin_OctreeZone.so
TYPE   RPATH FILE 
ET_DYN  -  Plugin_OctreeZone.so 

scanelf -r Demo_PCZTestApp
 TYPE   RPATH FILE 
ET_EXEC   -   Demo_PCZTestApp 
I can update the CMake files with the INSTALL_RPATH so the demo runs, is there a CMAKE settings variable or something else that I'm missing.

PS: The PCZAppMedia resource path is still missing from the resource template.
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 »

Yeah, the PCZ targets should probably keep the RPATH. I'll look into it. Right now, though, I'm getting some heap corruption on Linux again when closing the samples. I need to fix that first (assuming that it is, indeed, an error in the build system).
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 »

CABAListic wrote:You mean the projects inside Tests? We can fine-tune what gets built and what gets installed. We could simply provide another option (default off) to build the tests, if selected they would appear in OGRE.sln and could be built there, but still not installed. Another project is also doable, but we would have to include CMake code to find the built Ogre libraries.
Ok, that sounds fine. I was thinking of a separate project because I was thinking we might want the build environment separate to keep it tidier and not so huge, but I guess if it's defaulted to off that'll only affect the local builds of those that include the tests (like me :)).
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 »

I've updated the projects and now static building of the demos works. In VS2005, each demo is about 5Mb with all the plugins embedded, which is pretty good.

I noticed something though, I can't figure out why OIS.dll and cg.dll do not get correctly copied to the build/bin/release folder. Instead, they get copied to the debug version?? I've looked at the CMakeLists.txt in Dependencies which is assume where this comes from, and it looks ok, so I have no idea why it's doing this. Any ideas?
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 »

Excellent! I just moved flat this week, so I didn't have time to work on it, but since you took care of the static build I can focus on some cosmetics in the next few days.
I'll look into the dependencies problem, I was fairly certain they were copied correctly for me...
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 »

Maybe the problem with copying the release OIS.dll and cg.dll to the debug version is at the end of Dependencies CMakeLists.txt, the following doesn't look right:

Code: Select all

configure_file(${OGRE_DEP_BIN_DIR}/release/cg.dll ${OGRE_BINARY_DIR}/bin/debug/cg.dll COPYONLY)
configure_file(${OGRE_DEP_BIN_DIR}/release/OIS.dll ${OGRE_BINARY_DIR}/bin/debug/OIS.dll COPYONLY)
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 »

dermont wrote:Maybe the problem with copying the release OIS.dll and cg.dll to the debug version is at the end of Dependencies CMakeLists.txt, the following doesn't look right:

Code: Select all

configure_file(${OGRE_DEP_BIN_DIR}/release/cg.dll ${OGRE_BINARY_DIR}/bin/debug/cg.dll COPYONLY)
configure_file(${OGRE_DEP_BIN_DIR}/release/OIS.dll ${OGRE_BINARY_DIR}/bin/debug/OIS.dll COPYONLY)
You're spot on, thanks. Stupid copy&paste mistake.
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 »

Ah, I missed that, I was looking at the 'install' section. I've fixed.
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 »

CABAListic wrote:
Alright, it's done. The build now makes use of preprocessor defines given to the compiler, OgreConfig.h remains untouched. Furthermore, I've taken a slightly different route to creating the final OgreConfig.h (the version which gets installed) by taking the original OgreConfig.h and modifying its contents as necessary. This ensures that any changes made to that file are carried along.
I'm having trouble understanding how the preprocessor defines / install config.h are determined on Linux. For example from the installed config.h file I don't see the defines for endianness, headers etc:

Code: Select all

#define OGRE_CONFIG_LITTLE_ENDIAN 
#define HAVE_UNISTD_H 1
..
And in the CMake files there doesn't appear to be tests for the above, e.g:

Code: Select all

INCLUDE (${CMAKE_ROOT}/Modules/TestBigEndian.cmake)
TEST_BIG_ENDIAN(OGRE_DETECT_ENDIAN)
IF (OGRE_DETECT_ENDIAN)
...

INCLUDE ( ${CMAKE_ROOT}/Modules/CheckIncludeFile.cmake)
CHECK_INCLUDE_FILE("unistd.h" HAVE_UNISTD_H)
CHECK_INCLUDE_FILE("string.h" HAVE_STRING_H)
CHECK_INCLUDE_FILE("memory.h" HAVE_MEMORY_H)
etc..  
Also the installed OGRE.pc seems to be missing some of the above defines, for example:

Code: Select all

CMAKE     Cflags: -I${includedir} -I${includedir}/OGRE 
Autotools Cflags: -I${includedir} -I${includedir}/OGRE  -DOGRE_GUI_GLX -DOGRE_CONFIG_LITTLE_ENDIAN
On a side note it would would be nice to have an option to specify the gui type on Linux to replicate ./configure --with-gui=type ( gtk,Xt).
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 »

dermont wrote: I'm having trouble understanding how the preprocessor defines / install config.h are determined on Linux. For example from the installed config.h file I don't see the defines for endianness, headers etc:

Code: Select all

#define OGRE_CONFIG_LITTLE_ENDIAN 
#define HAVE_UNISTD_H 1
..
So far, I'm only using the config.h file for configuring the settings of OgreConfig.h and nothing else. But you're right, this needs to get in, I simply missed it so far. Thanks.

Also the installed OGRE.pc seems to be missing some of the above defines, for example:

Code: Select all

CMAKE     Cflags: -I${includedir} -I${includedir}/OGRE 
Autotools Cflags: -I${includedir} -I${includedir}/OGRE  -DOGRE_GUI_GLX -DOGRE_CONFIG_LITTLE_ENDIAN
Once they're in the config.h, they are no longer needed. I don't know what OGRE_GUI_GLX is supposed to accomplish, though. It doesn't seem necessary to use Ogre in any way.
On a side note it would would be nice to have an option to specify the gui type on Linux to replicate ./configure --with-gui=type ( gtk,Xt).
I left it out because from my impression the gtk code seems deprecated and does not reflect more recent additions to RenderWindow features. If I'm wrong here, we can put it in, but otherwise I don't want to complicate the build system (same with DevIL support).
Locked