Clean build of 1.2 in MacOS

datamagik · Post by **datamagik** » Thu Feb 22, 2007 3:19 am

Has anybody got this working? I finally got an SVN of 1.2 from a few days ago to build using make in BASH, but can't build the demo to it.

The 1.2 XCode doesn't seem to build either. I am able to do a clean build of 1.0 library and all the examples from XCode, debug and release, universal binaries. I have also done a full build in Windows (both Dev-C++ and CODE::BLOCKS) both library and demo app, and can build the Linux version in terminal under Ubuntu Linux 7.04b3.

If no one else can get 1.2 working under MacOS then I would like to try to fix it. If other folks are able to build and all that's broken is my understanding of the project then I'd like to fix that too.

Any help is greatly appreciated!

hybrid · Post by **hybrid** » Thu Feb 22, 2007 8:26 am

There are some files missing in the XCode project, and two code fragments are wrong (with fixes in latest SVN revisions). After fixing those you should be able to compile for OSX.

kschn · Post by **kschn** » Thu Feb 22, 2007 10:33 am

Just like hybrid said, the 1.2 version isn't broken or anything ...

The only reason you can't compile it is because there have been files added since 1.0 and Xcode doesn't compile them.

To fix that you must add those "new" files into the Xcode project (I don't know if there's a way to make Xcode check a folder so it compiles all his conten ...).

The other problem is a typing mistake (again like hybrid said) if I remember correctly.

I can give you my custom version of the Xcode project, but since I tweaked several things it might not work on your system.

Do you have a intel based cpu or a ppc ? I have made the lib so it's optimised for g4 and not universal (meaning it won't work on intel). Do you know how to change those settings ?

My version : http://kschn.free.fr/irrlicht/IrrlichtX ... OSX1.2.zip

It also contains the xml fix for macOS which hybrid post the other day.
Tell me if it don't works and if you don't know how to change settings for you machine. I'll post a universal one.

I hope this helps you

Edit: Forgot to say : extract the zip in you folder /source/Irrlicht in the 1.2 folder.

datamagik · Post by **datamagik** » Thu Feb 22, 2007 8:20 pm

Merci beaucoup!

The copy I checked out of SVN is "broken". If you download the "release" zip file or SVN all the files you will still not have something that will build either from XCode or command line.

Perhaps we can assemble the missing pieces that Mac users have created and add those to the SVN source to fix this. Mac OS X is built on a genuine BSD Unix foundation and should be able to build the library from the makefile as easily as Linux does. I have made a few small changes to the makefile to do this, but there was an error in the placement of one of the included headers in CIrrDeviceMacOSX.mm (it was placed within a test for one of the preprocessor flags that could logically placed there). It also appears there are a number of Cocoa dependencies that are preventing it from compiling properly from command line.

I added your changes to the current working version in SVN, and added the i386 to the library. The Intel iMac is able to build and run applications for either processor so I do not believe this as a factor. When I cleaned all objects and did a build it stopped with an error.

Are you able to add those files you gave me to a copy of the irrlicht project in SVN and get it to build? It took about 5 minutes for the SVN checkout, a few more to unzip your file and add to that copy. If you do this and go into the XCode project are you able to clean the library and do a full build?

I am not a Windows programmer by experience, but I was able to do just that with two diffferent development systems in Windows. If I check out a fresh copy of the project I can rebuild the entire library from scratch. I am not fond on command line build systems, but I was eventually able to learn enough to rebuild the library from scratch in Linux too.

The fact that the 1.2 engine does not seem to want to compile on my system is why I choose the word "broken" to describe the MacOS side. If you can in fact get it to build from the SVN copy as is, I would like to figure out what I'm doing wrong here. If you cannot build from the SVN copy without changes then please consider adding your files to the SVN code base as a contributor!

Thank you again for your help!

hybrid · Post by **hybrid** » Thu Feb 22, 2007 11:38 pm

The problem with the OSX port is that no one of the current developers owns a Mac. So changes which have to be reflected in the OSX part are not recognized automatically (we simply don't see compiler output) and new features can often not be added due to lack of knowledge. And the XCode project is pretty weird, so no chances to add files without running XCode.
BTW: The BSD background is pretty far when you look at the Object-C code with Carbon fragments in the OSX device

datamagik · Post by **datamagik** » Fri Feb 23, 2007 12:40 am

Yeah I agree about the mix of objective C at the engine level being awkward.

The engine does some mixing of high and low level OS functions in the CIrrDevice<OS>.cpp files. You get away with it better in Linux because X Window is a lower level windowing library.

I would draw an analogy that Carbon is like X, and Cocoa (I remember that carbon is an element in cocoa and other carbohydrates) is more like the Gnome desktop.

As I spent about 4 or 5 hours last night trying to get the library to build from the makefile it seemed that the extra layers of dependencies to support the desktop from within the engine would make it hard to get that going without a lot of work. My present inclination is to redo the CIrrDeviceMacOSX in C++ and move the MacOS files to the same directory as their Linux and Windows counterparts. I may create an Irrlicht.xcodeproj to live side by side with it's CODE::BLOCKS et al peers, with separate project files for the examples as has been done with other IDEs.

I think it would make more sense for long term project planning to try to move the parts of the SDK that are windowing system dependent OUT of the engine (the engine just needs a screen to draw to and enough code NOT to defeat window systems where in use). The use of Cocoa in MacOSX like Gnome or KDE desktops in Linux makes perfect sense at the application level (in our code base here represented by the example apps, especially "Demo").

XCode is perfectly capable of including entire directories by reference. The problem has been many directories contain files that didn't compile on MacOS so rather than include directories and modify the offending files to simply do nothing in MacOS builds (as with the CD3D8 files which are referenced in the Linux makefile but are rendered harmless with judicious use of #ifndef/#endif preprocessor bracketing), earlier contributors to the Irrlicht MacOS support just "manually" added only those files they knew about.

One of the half dozen variants I've played with since deciding that I wanted to use Irrlicht for cross-platform 3D development, is one where I have created subdirectories of the source/irrlicht directory and followed the API namespace hierarchy (and I'm looking at the project files for Visual Studio, Dev-C++, and CODE::BLOCKS as models for guidance).

Arranged like this it seems like it would be easier for contributors to keep their work as platform independent as possible, and maintainers for each platform would know to expect funny business in the source/irrlicht/os area. The most recent area of trouble seems to have been the moving of portions of the PNG libraries into subdirectories by contributor. If the XCode project included the entire source/irrlicht/libpng by reference then it would be immediately obvious to the first developer trying to rebuild the library where the trouble was coming from and would force them to immediately add the needed #ifndef MACOSX/#endif bracketing to remove the offending portions. Ideally the sections that were OS specific would even be in separate directories.

hybrid · Post by **hybrid** » Fri Feb 23, 2007 9:11 am

Hmm, the libpng stuff should be easier to find now. All files in the libpng dir might be of interest and all further away are not. So just include all top-level files without going into the sub-directories. You might get problems with the optimized variants for ix86 architecture, though, which would only be excluded if we would use the configure scripts.
I'm not sure why the OSX parts have been moved to a separate directory. It does not really make sense to me, but I also never questioned it. It seems reasonable to merge the OSX stuff with the usual directory. A better directory layout based on the namespace might also be nice , I should ask Niko about it.
Separating the window handling and the rendering is not possible, though, because window creation is often dependant on the render driver. If someone comes up with a better separation I'll definitely consider it, but until now I did not find a satisfactory solution.

kschn · Post by **kschn** » Fri Feb 23, 2007 12:07 pm

I didn't know for the iMac compatibility. I believed it could only run universals apps or apps made for x86.

But if your error is at compilation it's probably not a g4/x86 problem, so it makes sense ...

I think I already got a svn checkout working once but can't remember when it was. At first I had the exacts same problems as you but the mac errors are usually the sames so the more you compile irrlicht the easier it gets.

Anyway what was your error ? Can you tell me a little more about it ? (since I got a new "broken" irrlicht 1.2 from the website and pasted my changed and it worked I'm wondering a little bit what it was.)

I'll try to compile a fresh svn checkout as you suggested. I'll log all the changes I've done also just in case ...

hybrid: I think the reason why the OSX parts moved to a separate directory is because it's somehow still experimental. If the team don't have a mac developper then you probably just sticked with the version made for irrlicht 1.0, then the errors makes senses.

Anyway this is rather sad, irrlicht works really well on mac but I think that most of people who download it and sees the compilation failing might rather give up than get some nights or weeks to make it works.
Since the mac errors are not errors (from my point of view) you should really consider recruit someone using a mac in the team, just to make sure that the versions 1.x you publish works out of the box (you don't even have to give him svn acces, just making sure that irrlicht compiles is enough, then he could send the changes to a real developper).

kschn · Post by **kschn** » Fri Feb 23, 2007 1:20 pm

Hum, never thought about is before but ...

There's a zip release of irrlicht with the lib already compiled for windows.
I understand the basic reason why there's not one for linux, but macOSX is a little bit like windows if we speaks in terms of applications no ? Since we all run the same OS (ppc and x86 difference excluded but universals are here for that.)

Why not include a working universal lib ? This way using irrlicht on mac would become as easy as windows. And if the user wants he can still compile it and tweak it to suits its needs no ?

kschn · Post by **kschn** » Fri Feb 23, 2007 2:08 pm

Well I got it to compile and it's now working. This version is from rev 486 (did the checkout several hours ago.)

But this time I did change quite a lot of things ...

Here's the /irrlicht zip (I cannot include the build with sorry it's too big.) which must go to /source

http://kschn.free.fr/irrlicht/Irrlicht.zip

This time it should really works since it's the basic project with no tweaks, universal binary ... etc and probably from the same rev you're using.

Well the things that were wrong this time:

-2 files do not exists anymore (Writepng.c and CZBuffer2.h .cpp) but are in the Xcode project (so it says it can't find the files ... pretty logic but well ...)

-There were a lot of .h from /include that were not in the Xcode project
-Same thing with the /source (it goes in engine normally).

-There was a configuration problem : the project is "correctly" (actually it isn't but the config works) configured with the debug build selected but is in relase mode (and the release mode isn't configured at all). So when Xcode is done with the lib, it tries to link it searching it in /build/Debug while it's in /build/Release ...
You must change the lib search path to : $(inherited) $(BUILD_DIR)/$(CONFIGURATION) So it gets the right lib folder for any config.

-There were also a lot of problem with the zlib jpeglib libpng ... etc (I'm not sure if I did the right thing there ... I included all the files without the subfolders but then there were compilation errors because some files are not meant to be included for macs ... I also definded several things ...). So in this version png, jpg and zlib might not work (I don't have time to test it sorry).

Anyway with this you should be able to use irrlicht on your mac. But keep in mind that it should only be used for dev pruposes until someone definatly fix this, I absolutly can't garantee that I did the right things ... I'm really sorry, I don't have time to do something better right now.

Edit: hum sorry for the 3 posts, but since it took so much time to compile and wait at each errors and it was so much boring I spammed a little bit without realizing :p

datamagik · Post by **datamagik** » Fri Feb 23, 2007 6:20 pm

Thank you for spending more time loooking into this!

BUT I do not want to use yet another spin off of the code base. If you have made changes to the MacOSX.xcodeproj file please send it to Niko or one of the contributors so it can be included in the code base. Multiplatform support means the same code base builds to all platforms. Lets fix this. It doesn't make sense for MacOS developers to each have to create their own private mods just to be functional.

I can download the SVN unchanged on Windows and Linux and it builds either from shell or IDE.

Yesterday after downloading a fresh copy of SVN 486 and adding your files I hit the same snags in compile I had before (I've been fiddling with 1.2 on MacOS off and on for over a month, it's teaching me Niko's well written code base and like you said the problems become more familiar and easier to spot). I got that spin off to compile with the same link errors as before. Sooo...

I went back to the copy of SVN486 I'd dl'd on 2007-02-21 and continued the debugging process and systematically eliminated the link errors.

I got 1.2 to compile and link to demos

BUT. They don't run.

So I will continue to see what changes may be causing this. At least I am not alone in having these problems (experienced MacOS Irrlicht users are also having trouble with the lack of proper integration of MacOS tools into the project). And knowing that it's my lack of understanding of the tools, I can fix what is broken.

My job now is to fix the build tools for Mac OS in Irrlicht 1.2. There is no reason why the makefile can't work for Mac OS using BASH command line. I will need to convert CIrrDeviceMacOS.mm to CIrrDeviceMacOS.cpp and probably use lower level Carbon calls to effect this, but it will be time well spent to have a reliable method of performing a clean build of the engine to the latest source on ALL platforms. It's the whole point of the exercise of a multiplatform engine.

The PNG lib stuff that was moved to deeper directory levels was done so as an organizational tool. There are files in all but one of the deepest directories in the the new source/irrlicht/libpng/contributors directory that are needed for the project. The fact that this new structure is tripping me up making changes to my IDE project file (the IDE in this case being XCode, but it could be Metrowerks Codewarrior, CODE::BLOCKS for MacOS or anything else), is the argument in favor of my leaving the rest of the library structure alone. It was nice dividing Niko's code into it's high level name space categories ::CORE, ::AUDIO, ::IO, ::OS, ::VIDEO, etc, but I found I was creating more work for myself trying to match changes to the latest SVN to my bold new structure. I'll leave it alone for now. If I can make a useful contribution to Mac support for the project maybe then I can approach Niko with the suggestion that he divide the code up a little bit. Or perhaps by then I'll be so familiar with the project structure I won't need that study aid.

In the process of creating a new more consistent Irrlicht.xcodeproj I will add a directory irrlicht/make at the same level as irrlicht/bin, irrlicht/source, etc and put the makefile and IDE project files for all dev tools I have there. I was never able to make Visual Studio Express C++ build the project (missing D3DX8 SDK files) but both Dev-C++ and CODE::BLOCKS build for Windows. I think I need to change some settings in a copy of the Linux version of the C::B project from another Irrlicht developer to get that to build on my Ubuntu 7.04b3 box, but the makefile works fine there. This engine is well written and with some fine tuning it should be able to build a single application code base targetting Mac OS, Windows, and Linux.

Wish me luck!

kschn · Post by **kschn** » Fri Feb 23, 2007 7:18 pm

Congratulation for your 1.2 build

I aggree with you on the purpose of multiplatform code.
If you really manage to make a CIrrDeviceMacOS.cpp it would be awesome

Irrlicht definatly deserve something like this ! And as you asked : good luck

Boomba · Post by **Boomba** » Sun Feb 25, 2007 12:45 am

I am definitely waiting for a solution to this problem. I have yet to find and open source cross platform game engine that I can get working on my OS X

good luck

Boomba,

jonasled · Post by **jonasled** » Mon Feb 26, 2007 9:41 pm

I had the same experience. I'm was looking for an easy to use cross platform 3D engine. Irrlicht is it, but for the reasons that hybrid has explained, getting 1.2 to run on MacOS X is a bit tricky. The community is very responsive so I urge Mac users to get involved rather than complain about the lack of support. Not that anyone in this thread is guilty of that. However, having said that I agree that at the end of the day the current state of affairs isn't exactly doing wonders when it comes to attracting new Mac developers. We need to fix this! This is a great engine. It deserves a better Mac fate.

At the moment I have a hard time keeping up with things having a lot of stuff to do at work, but as soon as things cool down a bit I will help out. The least I can do is contribute my working Xcode project. However, at the moment it compiles only against an older SVN revision.

@kschn: thanks for the fix list! It will no doubt come in handy.