Horde3D

Ok... I'm convinced that for non-command line users waf is not that good an idea.

The problem with the new version applies equally to cmake: At the moment there is 2.4 and 2.6 is in beta stage.
Regarding premake: I find it a bit strange that some major linux distributions don't include it.
But on the other hand the scripting language of cmake, especially regarding "if" and undefined variables is really strange.


I have attached a proof of concept cmake build environment for cmake 2.4. Tested only on Linux. Probably there will be linker errors.
cmake does not like spaces in file names, so I had to remove these spaces: Horde3D Engine, Horde3D Utils, Collada Converter.
Now unzip cmake-r?.zip inside the trunk folder which contains the directories Extensions and Horde3D. To prevent messing up the source directories create a new directory called "build". Go into that directory and call cmake: "cmake .." (maybe with your target specification if the default is wrong for you).
I have enabled the terrain extension by default in my cmake configuration. So uncomment the lines inside egExtension.cpp, remove the pragma and change the include path to "Extensions/Terrain/Source/extension.h".
I'm still thinking about a way to generate egExtensions.cpp automatically.

I always prefer compiling from within an IDE (MSVS and CodeBlocks), so what I would like in a build system is for it to output IDE-workspace files (not to actually build the project)...

I think this approach is much better as it supports IDE compilation (outputting of workspaces) and cmd-line compilation (outputting of files for other build systems, such as make...).

Ja, this is pretty much what CMake does. It outputs visual studio (or XCode on the Mac) project files, or builds directly from the command line.

@CodePoet: Those files seem to work for me, though I haven't tested them extensively.

_________________
Tristam MacDonald - [swiftcoding]

@swiftcoder: That's good. On which platform / environment have you done your tests?

I made a bit of progress today regarding easy enabling / disabling of extensions. I want to do a few more tests, then I'll upload the updated cmake environment here.

How should we handle the glfw dependency? The included libglfw.a does not work on 64bit Linux systems but is (more or less) silently ignored when a compatible libglfw.a exists in the search paths. Remove it? Include glfw as a whole and compile it on demand using cmake?

Mac, command line - I will test with XCode as well once I get the chance.

I would be tempted to include the whole thing - otherwise we will have to put together a pile of binaries for different platforms/architectures.

_________________
Tristam MacDonald - [swiftcoding]

cmake-r2.patch.zip:
* easy enabling / disabling of extensions using ccmake
* includes complete glfw 2.6.0 distribution

Now in patch format:
Before applying you have to remove the spaces in the directory names of Horde3D/Source/...; a patch that does this would contain all the files there, so it's for now easier this way.
Patching:
patch -p1 --dry-run < cmake.patch
To really apply omit --dry-run.

Is there still interest in a new build system based on cmake? Has someone tested the current version under Windows with Visual Studio?

Yes of course. Unfortunately I hadn't time to look at your files yet. Sorry for that. I will test them on linux and windows, and if it'll work fine, I will integrate them in the SVN.

Volker: Take your time. It would be great to have this in the 1.0 release.


I'll add an install target in the next days. Any ideas where to put the files under Windows / Mac by default?

I am going to have to tweak these a little bit for the Mac, hopefully in the next couple of days. Basically it has to build a 'framework bundle' (as opposed to a shared library) named 'Horde3D.framework', and it needs to be installed into '/Library/Frameworks/'.

I will post as soon as I have it tweaked.

_________________
Tristam MacDonald - [swiftcoding]

cmake build system now includes install target for linux platforms.
Horde3D.so --> lib
Horde3DUtils.so --> lib
C++ Bindings --> include/horde3d
An arbitrary prefix can be specified using ccmake.

cmake-r3.patch.zip

Instructions for applying: see above (cmake-r2.patch post)

Hi codepoet, I just want to thank you for all the effort you have put into the CMake build system, i really appreciate it.

I Haven't had time to test it, but will do so next thursday. Keep up the good work.

I'd like plain make file more but cmake is fine too.
there are other tools like scons, premake etc... more or less they are the same, so in my opinion cmake fits well
thanks

You get plain make files under Linux by using cmake. The idea was to have a consistent and cross platform build system with optional IDE integration. cmake does that and was easy enough to implement so far.

Finally I started with testing your CMake patch. Unfortunately I didn't get GNU patch to integrate it correctly so I had to apply it manually.

So far I came across two problems. The first one was a missing
in the CMakeFiles.txt of the Horde3D Utils configuration.

This was solved easily. The second problem does not make sense to me.
All the samples are linking against the correct version of glfw.lib. But for some reason I got linker errors to all glfw functions, that they can't be resolved.
e.g.

Does anyone know what may be the problem in this case? I guess it has something to do with the "Compile as C Code" settings for the glfw Library. But I coudn't solve it in a rush.

Compiler used was Visual Studio 2005 SP1