CMake build system for Cthugha *looking for testers*
-
- 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*
Gah, sorry, you're right. Slipped my mind I had created that file. It's committed now
-
- 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*
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:
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
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.Code: Select all
#include <OgreConfig.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:
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.
Code: Select all
#ifdef OGRE_CMAKE_BUILD #include "OgreGeneratedConfig.h" #elif // previous contents from OgreConfig.h #endif
- 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.
- sinbad
- 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*
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).
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).
-
- 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*
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.
-
- 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*
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?
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?
- Noman
- 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*
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...
It's pretty common in the linux projects...
-
- 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*
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).
-
- 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*
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.
- sinbad
- 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*
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.
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.
-
- 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*
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
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
- sinbad
- 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*
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).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
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.
-
- 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*
You're right, I forgot about the plugins.cfg. Yes, that effectively makes all built plugins a dependency.
-
- 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*
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.
Aside from that, anything else I should be aware of for a correct and usable static build? I haven't investigated any further yet.
- sinbad
- 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*
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.
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.
-
- 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*
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.
-
- Bugbear
- Posts: 812
- Joined: Thu Dec 09, 2004 2:51 am
- x 42
Re: CMake build system for Cthugha *looking for testers*
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:
From the cmake install dir this doesn't appear to be the case.
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.
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
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
PS: The PCZAppMedia resource path is still missing from the resource template.
-
- 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*
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).
- sinbad
- 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*
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 ).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.
- sinbad
- 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*
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?
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?
-
- 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*
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...
I'll look into the dependencies problem, I was fairly certain they were copied correctly for me...
-
- Bugbear
- Posts: 812
- Joined: Thu Dec 09, 2004 2:51 am
- x 42
Re: CMake build system for Cthugha *looking for testers*
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)
-
- 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*
You're spot on, thanks. Stupid copy&paste mistake.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)
- sinbad
- 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*
Ah, I missed that, I was looking at the 'install' section. I've fixed.
-
- Bugbear
- Posts: 812
- Joined: Thu Dec 09, 2004 2:51 am
- x 42
Re: CMake build system for Cthugha *looking for testers*
CABAListic wrote:
And in the CMake files there doesn't appear to be tests for the above, e.g:
Also the installed OGRE.pc seems to be missing some of the above defines, for example:
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'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: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.
Code: Select all
#define OGRE_CONFIG_LITTLE_ENDIAN
#define HAVE_UNISTD_H 1
..
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..
Code: Select all
CMAKE Cflags: -I${includedir} -I${includedir}/OGRE
Autotools Cflags: -I${includedir} -I${includedir}/OGRE -DOGRE_GUI_GLX -DOGRE_CONFIG_LITTLE_ENDIAN
-
- 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*
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.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 ..
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
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).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).