CMakeLists.txt changes under Linux

Hello.

I am currently looking for a GUI as I don't have enough time to create one from scratch (I'd love to but I'd love to actually make progress in my game too). I decided to try QuickGUI but I've encoutered a few problems (Ubuntu Linux).

I don't install the libraries I use for my game on my system. Instead, I build them and define te correct include/lib path when I build the game (instead of relying on /usr/include or /usr/local/include). Your CMakeLists.txt file don't handle that scenario (it searches for a pkgconfig file and then under /usr/include and /usr/local/include). You will find hereunder a patch for the CMakeLists.txt that allow, when your FindDependency fails, to enter manually the path to the dependencies (OIS and Ogre). I successfully built your library with this CMakeLists.txt but there are some remaining issues :
- I need to run cmake 3x in order to generate the Makefile (first time it asks me for Ogre, second time its asks me for OIS and third time it completes the Makefile creation).
- It won't build the editor, no matter what I set to the option (tried ON and TRUE).

I am no expert with CMake, I most likely did something wrong but I can't find out what.

I'll stop for today and will most likely try to integrate the GUI during the week-end but I thought it could be useful to post this in order to gather some remarks / reactions.

Patch:

--- CMakeLists.txt.orig 2009-09-10 20:06:00.000000000 +0200
+++ CMakeLists.txt 2009-09-10 23:15:57.000000000 +0200
@@ -6,26 +6,39 @@
option(DEBUG FALSE)
if (DEBUG)
set(EXECUTABLE_OUTPUT_PATH "${CMAKE_SOURCE_DIR}/bin/Debug" CACHE STRING "")
-else()
+else(DEBUG)
set(EXECUTABLE_OUTPUT_PATH "${CMAKE_SOURCE_DIR}/bin/Release" CACHE STRING "")
-endif()
+endif(DEBUG)

# Packages
find_package(Dependencies)
-include_directories(${DEP_INCLUDE_PATH})
if (NOT OGRE_FOUND)
- message(FATAL_ERROR "OGRE not found!")
-endif()
+ find_path(OGRE_INCLUDE_DIR ogre.h .)
+ find_library(OGRE_LIBRARY OgreMain PATH .)
+ if (OGRE_INCLUDE_DIR AND OGRE_LIBRARY)
+ set(DEP_INCLUDE_PATH ${DEP_INCLUDE_PATH} ${OGRE_INCLUDE_DIR})
+ else(OGRE_INCLUDE_DIR AND OGRE_LIBRARY)
+ message(FATAL_ERROR "OGRE not found!")
+ endif(OGRE_INCLUDE_DIR AND OGRE_LIBRARY)
+endif(NOT OGRE_FOUND)
if (NOT OIS_FOUND)
- message(FATAL_ERROR "OIS not found!")
-endif()
+ find_path(OIS_INCLUDE_DIR OIS.h .)
+ find_library(OIS_LIBRARY OIS PATH .)
+ if (OIS_INCLUDE_DIR AND OIS_LIBRARY)
+ set(DEP_INCLUDE_PATH ${DEP_INCLUDE_PATH} ${OIS_INCLUDE_DIR})
+ else(OIS_INCLUDE_DIR AND OIS_LIBRARY)
+ message(FATAL_ERROR "OIS not found!")
+ endif(OIS_INCLUDE_DIR AND OIS_LIBRARY)
+endif(NOT OIS_FOUND)
+
+include_directories(${DEP_INCLUDE_PATH})

# Build Options
if (DEBUG)
set(DEBUG_FLAGS "-g")
-else()
+else(DEBUG)
set(DEBUG_FLAGS "-w -s -Os -O3 -fexpensive-optimizations")
-endif()
+endif(DEBUG)

# Build Targets
add_subdirectory(QuickGUI)


Sebastien

Sebastien,

First, thanks for using and helping to improve QuickGUI! Now, as for the editor, are you encountering an error or does it just not build? If you're encountering an error, that's because it depends on the Ogre trunk, 1.7.0. Otherwise, try typing "ccmake ." rather than "cmake ." to present you with a command line GUI option editor where you can change options easily.

Now, as for your custom build method, take into account that QuickGUI is a library and can be packaged with your program, never requiring the end-user to compile it. If you still want to continue with this method, however, I'll try and give you a semi-simple method of achieving it. Since there is no standard location to put your own packaged includes in, the only option is to allow the packager to manually set their own include directory. I've added on option to disable pkg-config, which on my setup correctly creates variables for OGRE/OIS_INCLUDE/LIB directories which may then be set manually from ccmake or through the CMakeCatch.txt file. If you could check out the current source, (instructions here), and test that this works for you, that would be great.

I appreciate the work you put in on the patch, but I because I've modified that file significantly since the 9.07 release and because all the heavy lifting for the dependency finding is done in the CMakeModules/Find<PLATFORM>Deps.cmake scripts, I (hopefully) fixed it in an (again hopefully) cleaner manor.

Thanks again,
-Calder

Hello and thank you for the quick reply.

The problem is that it just doesn't build (I am not in front of my home computer but I think I was displaying something like "Building QuickGUI" then all the building log lines and then nothing where I was expecting "Building QuickGUIEditor"). No errors are shown. I'll try ccmake later this week-end.

About the library thing and packaging it with my program, here are my thoughts. I know that I shouldn't have any problem when compiling QuickGUI under Windows and then only use the DLL and the LIB/INCLUDE files. However under Linux, I am not so sure about being able to compile it and then giving away the .so and the headers because of the many Linux variants and all of that. So, currently, every Linux user of my game/engine needs to compile its dependencies. There is surely a way to better handle this but because we are only two people currently working on the game, it is currently not an issue (I'll look into this later but if you have any links, I would gladly accept them).

Don't worry about the patch, I am no CMake expert and I only tried to make it work the way I wanted. I'll checkout the latest revision this week-end and give it a try.

Thank you,
Sebastien

Ok, if you still encounter the editor problem with the current source, please post the entire build log and your modifications to CMakeCache.txt. As I said, I've done a significant amount of refactoring of the CMake code in the last two and a half months; what is now a fairly clean and stable build system was then really a hacked-together alternative to Code::Blocks. Also, the editor isn't quite finished yet, so while it's usable it does have quite a few quirks.

As for packaging libraries for Linux, I'm not absolutely sure, but I think the only two fundamentally different Linux architectures are 32-bit and 64-bit Linux kernels, and between those libraries are compatible across different distributions. Again, I could be wrong.

Anyway, thanks so much for all the debugging help; when you're writing and testing something on one or two computers it's hard to assess how it will act on hundreds or thousands of different configurations.

Hello again.

I tried the SVN version of QuickGUI. The build was much easier but I still had to modify the CMakefiles. I disabled pkgconfig with the corresponding option and had to re-run cmake (or ccmake). Then, I asked for the path to Ogre and OIS. After specifying them I had to re-run cmake to finish the generation.

Here is the cause of the problem (as I understand it): when disabling pkgconfig, it tries to have a value for OGRE/OIS_INCLUDE_DIR and OGRE/OIS_LIBRARY (debug and release) Once it have them, it correctly uses the OGRE/OIS_LIBRARY but the OGRE/OIS_INCLUDE_DIR is never used. The patch checks if we have valid values for them and adds them to DEP_INCLUDE_PATH.


Index: CMakeModules/FindLinuxDeps.cmake
===================================================================
--- CMakeModules/FindLinuxDeps.cmake (révision 991)
+++ CMakeModules/FindLinuxDeps.cmake (copie de travail)
@@ -44,6 +44,10 @@
if (OGRE_INCLUDE_DIR AND OGRE_LIBRARY)
set(OGRE_FOUND TRUE)
endif()
+ if (OGRE_FOUND)
+ set(DEP_INCLUDE_PATH ${DEP_INCLUDE_PATH} ${OGRE_INCLUDE_DIR})
+ endif ()

# Find OIS
find_path(OIS_INCLUDE_DIR OIS.h ${DEP_INCLUDE_PATH})
@@ -59,4 +63,8 @@
if (OIS_INCLUDE_DIR AND OIS_LIBRARY)
set(OIS_FOUND TRUE)
endif()
+ if (OIS_FOUND)
+ set(DEP_INCLUDE_PATH ${DEP_INCLUDE_PATH} ${OIS_INCLUDE_DIR})
+ endif ()
endif()


With that minor modification I was able to build QuickGUI correctly. QuickGUIEditor doesn't build but that's because I use Ogre 1.6 (is it noted somewhere that the editor needs Ogre 1.7 ? if not, you might want to add it to the wiki. Also, the latest release version on the wiki is the 9.0.5 instead of 9.0.7). Tell me what you think about this...

For now, I'll try to play a bit with the library before building an Ogre 1.7 and QuickGUIEditor.

Sebastien

Wow, you're completely right, the include_path bug was really dumb of me and should be fixed now. Thanks again for you continued help, though I'm afraid I'm going to have to subject you to one more round of Guinea pigging before we're through! If you could test out the current version that would be great.

As for having to run CMake multiple times, that's really how it was designed. The first run generates the Cache, the second run either lets you change build options, or individual paths, and if it did the former than it often requires a third run to manually configure the paths. The nice part is that you're using the same command for all three rather than a finicky abnd messy autoconf/automake/libtool build chain. Also, the wiki page was just outdated, thanks for pointing it out.

Well... it doesn't work... I don't know why but it seems the stuff you do with DEP_INCLUDE_DIRS isn't really used by cmake. I wonder why you use that DEP_INCLUDE_DIRS variable instead of adding the paths directly to DEP_INCLUDE_PATH.

To make if work, I removed the lines 30 and 65. Then, on lines 45 and 61 I changed DEP_INCLUDE_DIRS to DEP_INCLUDE_PATH.

It's no big deal to be the guinnea pig, I am glad to be helpful (once this stuff has been resolved, I might come back later to help on the FindWinDeps.cmake file).

Sebastien

PS: On the wiki, the frame with license, status, dependencies, etc still indicated 9.05 as the latest version (seems you forgot to change that one). I updated it.

The reason I'm using DEP_INCLUDE_DIRS rather than the old DEP_INCLUDE_PATH is that I don't want ambiguities in which library is used. Let's say someone was using your method of providing dependencies to link against Ogre 1.7, but still had Ogre 1.6 installed for other projects. Because DEP_INCLUDE_PATHS then lists /usr/local/include/OGRE before ../deps/include/Ogre or wherever you have the Ogre headers, it would still use 1.6 despite all your efforts to the contrary. It gets even messier if someone tries to uninstall Ogre but leaves the headers. Then you'll get a bunch of "symbol not found" errors because the headers a describing a version different than the one you actually have.

Now, as the for error, it occurred because in my extreme case of tiredness last night I wrote include_directories(DEP_INCLUDE_DIRS) rather than include_directories(${DEP_INCLUDE_DIRS}). *Doh* It (should) work now, so give it a try but keep your fingers crossed! :-S

I've now added a CUSTOM_DEP_DIR option, which will allow CMake some hard-coded guesses at the location of your custom dependencies in situations like yours. Currently, it will only work if your headers and libraries are in ${CUSTOM_DEP_DIR}/include and ${CUSTOM_DEP_DIR}/lib respectively, but I'd like to hear your input on the matter. Should I add other hard-coded guesses or split it into two options for CUSTOM_INCLUDE_PATH and CUSTOM_LIB_PATH respectively? Also, I've fixed an annoying capitalization bug which was causing find_library to fail when not using pkg-config.

Yesssss !

Now it works correctly. Thanks for the patches.

I also tried the CUSTOM_DEP_DIR and it worked for OIS (did not try with Ogre as I would have to re-run configure with a specific installation prefix). It worked with one minor issue: cmake asks for the CUSTOM_DEP_DIR and searches for OIS and Ogre at the same run. So, knowing that OIS was in the CUSTOM_DEP_DIR I had to skip the part where cmake asks me for the OIS include and libraries path and re-run it again. Some people could see this as "not working" as they specify the CUSTOM_DEP_DIR but cmake says directly after that that it didn't found the library. This could be a non-issue, maybe it should be better to leave it as it is and see if someone complains about it.

I personnaly think that the CUSTOM_DEP_DIR is a good idea and there is no need to split it. You can't support every setup in the world and I think the FindLinuxDeps.cmake does quite a good job in this state. People can use pkgconfig to configure their libs, they can specify a custom path which would correspond to a specific installation prefix they would have used when configuring Ogre or OIS for compilation and they can even specify directly the path to them. That's 3 different ways to specify the path and I think it is enough.

That's just my 2 cents.

Anyway, thank you for the quick replies,
Sebastien

Thank you Calder. I had asked him to take a look at this thread, since I work on Windows platform and am unfamiliar with CMake and Linux setup.

Well, any route around that would simply require way to many options and runs for the normal build scenario, which I didn't want to do. The compromise I settled on was that the user with the custom directory could simply remove the OGRE_LIBRARY_REL etc... variables after changing CUSTOM_DEP_DIR to make it automatically find them there. Because the custom dependencies are first in the path list, CMake will search there before continuing to the regular include paths, hence giving them priority if they exist.

Yeah, thanks to KFM for pointing me to this thread, I don't check these forums very often and for good reason. The writer of the entire library is much better suited to answering 99% of the questions; in fact, this is the first Linux specific question I've seen here. It's good to know that the CMake system has at least one user other than myself though!