Horde3D

As I wrote in my Python thread I got Horde3D to compile using a cross compiler under Linux: mingw32.

To get this working I had to do the following:
Linker error, related to confusion between pow and powf:


wgl seems to be unsupported by mingw32:


case matters on Linux:




utImage.cpp produces many warnings regarding conversion from "const char *" to "char *", but it works.


All other changes are related to makefiles. Simply replacing g++ with i586-mingw32msvc-g++, changing names of library files etc.


And here's my problem: It's not that easy to integrate the changes to the makefiles into the existing build system. Other problems like being unable to specify the compiler on Linux with the usual CC or CXX environment variables is not possible. Parallel compilation with -jN is not really supported....
I'm interested in moving away from the makefile approach to a platform independent build system.

I also thought about using CMake. But currently I don't have time to realize that. Any volunteers?

Sure, I'll do it. It will help me a lot under Linux when I can produce windows executables.

I prefer to use waf (was: bksys, fork of scons). Worked so far very good for me in some of my projects. Disadvantage for Visual Studio users is that, there will be no native build file for them. But I believe Visual Studio can execute any command to build a project and that would be enough to get the build button to work.

The only dependency of waf is Python, that should be no problem.

Never heard of it, but if you think it is easy to configure and maintain we can use it. I never used the makefile project under visual studio, but if that's the only problem, we can maintain visual studio project files separately.
Anyway, a big thanks for managing this.

+1 for cmake, it just works.

I had problems with scons in the past. If waf is a scons fork then i would prefer to have a cmake build system.

In principle I would also prefer CMake since I know that is widely used. But I don't have much experience with those build systems. Most of the time I used Visual Studio.

[edit] I added a vote to the topic

waf has not much to do with scons today. It's really simple:

Building the libHorde3D.so (or Horde3D.dll):

Really simple The files for the samples and Horde3DUtils are similarly simple.

Building:


I don't like cmake that much: If you are doing something wrong you never know if cmake is the problem or the created makefile / projectfile.

I think we can start with waf as long as noone makes CMake files. If that's the case we can think about it again.

Personally i will always use VS C++ compiler to build horde3d and not mingw32, i use multiple versions of gcc for different projects, including ARM programming, so i don't really like to mess with my configurations for Symbian compilation.

This doesn't really help me in any way, i will continue to use the visual studio solution files. But it may be useful for others

Waf is pretty much useless on the Mac (it would require rewriting major parts of waf itself), whereas CMake works flawlessly both with the Mac and with Visual Studio. Unfortunately I don't have the time to produce CMake files in the near future.

_________________
Tristam MacDonald - [swiftcoding]

So I think the long term goal should be CMake,... maybe I will find some time after next week to take a look at CMake.

DDd: Something better than the existing makefiles would be really usefull for me.

swiftcoder: I didn't know that. Is it really that bad? xmms2 uses waf and builds on OS X AFAIK. Could you test that?

Volker: If waf is really missing mac support I'll take a look at cmake.

It isn't so much that it doesn't work, more that it doesn't understand any differences between Mac and linux (or Windows for that matter).

CMake can output XCode project files (as well as Visual Studio project files) directly from the basic build system, which eases integration a lot. If we go with Waf, we will still have to maintain Visual Studio and XCode projects for those who need them.

_________________
Tristam MacDonald - [swiftcoding]

I'm not a big fan of CMake, the whole scripting is just to/so ...
Lets just keep it at some people like cmake others don't.

I always liked the approach premake has, it uses the lua language to as scripting interface and it will generate the build files for the target system.
It's clean, easy to use and works on mac, linux, windows, ...

CMake is more mature and has more features, but with some time and a couple of good lua scripts premake could be far better then cmake ever will be.

As for Xcode :: gnu make files work on mac, lua scripting has the *if(mac)* option but no xcode project files atm. XCode project files have been on the todo list for some while, they might even be in the svn version. (allot of that stuff has been on hold for the 4.0 remake of premake ...)

http://premake.sourceforge.net/what_is_premake
http://industriousone.com/post/subversion-shuffling

premake 4 appears to be interesting, easier than cmake, but not as powerful and will have features similar to cmake, but i don't think it would be very good policy to start using premake 3.5 something that is not going to be compatible with 4.0.