Compiling OpenXCOM on Mac OS X

[Dentrassi_BBQ]

Perhaps I'm missing something there? I couldn't find 10.4 SDK anywhere on my Mac partition, and my Xcode refuses to comply as well.

Yeah, it's not installed by default.  If you go back to the XCode 3.2.x installer, i think under [Installation Type] you can turn on the optional stuff.  MacOSX10.4u.sdk should be one of the options.  I don't have it in front of me, but that's what i remember.

It is a burden in terms of having to deal with SDL dependencies, some of which I had to recompile manually in order to make sure everything worked as intended. And even if manageable, I still see no viable reason why bother in the first place, no offence. If you take a look at these statistics - https://update.omnigroup.com/ (Overall > Major Version), you will notice that 10.4 constitutes only 21.8% of OSX market share and is dropping steadily. Of course, these are not backed by Apple, but I'm sure they are quite representative nevertheless. The aforementioned being taken into account - personally, I think it is not worth the hassle, at least on my part. On the other hand, if you feel comfortable about making such kind of a contribution - you are definitely welcome.

I'm *not* trying to start an argument, but your data shows that Tiger users are over a fifth of the market.  Again, unless there is a major burden supporting that particular compilation target, i would argue against turning our backs on millions of potential users.  And yes, i do intend to help share the burden after i get up to speed.

[SupSuper]

I figured out how to compile the source into a framework with Xcode

It may not be on topic, but i'm probably not the only person who also hasn't figured this out.  Do you have link you could point us to?

SDL_gfx includes an XCode project in the "Other Builds" folder, after upgrading and tweaking it should work fine.

I might commit the Xcode project once this is done to save all those steps.

Please do!

I no longer have access to a Mac so I can't maintain an Xcode project, you'll just have to follow marabus' instructions or ask him to post one.

[Dentrassi_BBQ]

The problem, however, lies with SDL_gfx, for there is no official precompiled package - you have to create it yourself.

Question: do all the dependencies have to be frameworks?  I built SDL_gfx using the standard configure/make/make install, which is all i know.  I did unpack the optional Project Build stuff and move them in with the other SDL_gfx sources, but can't seem to do much from there - the project.pbxproj loads into XCode as a plain text file and all the target/build submenus are all grayed out.  I crawled the web awhile looking for a tutorial, and saw lots of how-tos on making a .pbxproj but none on what to do with one.

[luciderous]

Question: do all the dependencies have to be frameworks?

Well, theoretically... no. But you are really asking the wrong question here. The "make" utility provides for a building environment only, nothing else. So when employed on OSX it should build any specific target the system requires, and in our case that would be a framework target. You should check it after doing "make install" - whether a SDL_gfx.framework is present in /Library/Frameworks or ~/Library/Frameworks. If not, then you've got a problem there, since it would imply that you have to build the entire OpenXcom+dependecies stack using this method and it would be quite a feat if achieved. And of course, that is not something I'm quite skilled in, not to mention the irrelevance of such a method if there is a full-blown Xcode building environment at your disposal. Therefore I'd strongly recommend you to get better acquainted with Xcode - it is very easy to grasp, and is definitely more logical and less arcane than the whole "make" lingo.
And concerning your lack of luck with .pbxproj files - there is no wonder you've got issues, since these are project files for Project Builder application, the long time obsolete ancestor of Xcode. That is what I meant in the beginning of my "compilation guide" when I mentioned SDL_gfx to be ill-maintained. To get you up to speed fast, I suggest you try my project files instead - https://www.mediafire.com/?k13ii1v0hl6hbai
But be advised that SDL_gfx is dependent on SDL.framework, so the latter should be installed preliminary at a designated location in order for SDL_gfx to build successfully.

P.S. There is quite a good reading on frameworks in case you need to dwelve further - https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFrameworks/Frameworks.html

[SupSuper]

IIRC, I managed to get SDL_gfx built just by renaming the included file in "OSX-PB-Xcode.zip" from .pbproj to .xcodeproj, so Xcode would open it and automatically upgraded it, and then I fixed up any remaining errors. Maybe I just got lucky.

[Dentrassi_BBQ]

<snip>
The "make" utility provides for a building environment only, nothing else. So when employed on OSX it should build any specific target the system requires, and in our case that would be a framework target. You should check it after doing "make install" - whether a SDL_gfx.framework is present in /Library/Frameworks or ~/Library/Frameworks. If not, then you've got a problem there, since it would imply that you have to build the entire OpenXcom+dependecies stack using this method and it would be quite a feat if achieved. And of course, that is not something I'm quite skilled in, not to mention the irrelevance of such a method if there is a full-blown Xcode building environment at your disposal. Therefore I'd strongly recommend you to get better acquainted with Xcode - it is very easy to grasp, and is definitely more logical and less arcane than the whole "make" lingo.

I agree that 'make' builds what is required for the target system.  Let me offer a slight correction: frameworks are not required by OSX.  I've built scores of packages through fink, and none of those created a framework.  Apple may prefer frameworks, but dylibs and such still work fine.  I know this much, since i volunteer as a package maintainer for the freeciv package in fink.  In answer to your question, SDL_gfx installed into /usr/local/libs.  It wasn't particularly hard to add the header files to the XCode project alongside the other files, but i'll take your advice and rebuild SDL_gfx.  I do also intend to learn more about XCode, but haven't yet found a good starting point.  I will say this, though: the average linux user can build most anything with just "./configure;make;sudo make install".  No special forms of logic are needed for the end user, though developers do need to be skilled in the arcane.  There might be some exceptions in the world of Gnome, however.

And concerning your lack of luck with .pbxproj files - there is no wonder you've got issues, since these are project files for Project Builder application, the long time obsolete ancestor of Xcode. That is what I meant in the beginning of my "compilation guide" when I mentioned SDL_gfx to be ill-maintained. To get you up to speed fast, I suggest you try my project files instead - https://www.mediafire.com/?k13ii1v0hl6hbai
But be advised that SDL_gfx is dependent on SDL.framework, so the latter should be installed preliminary at a designated location in order for SDL_gfx to build successfully.

P.S. There is quite a good reading on frameworks in case you need to dwelve further - https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFrameworks/Frameworks.html

I will investigate that reading closer, thank you.  However, i question the wisdom of relying upon a dependency as dodgy as this, but of course that's all up to SupSuper!

[Dentrassi_BBQ]

IIRC, I managed to get SDL_gfx built just by renaming the included file in "OSX-PB-Xcode.zip" from .pbproj to .xcodeproj, so Xcode would open it and automatically upgraded it, and then I fixed up any remaining errors. Maybe I just got lucky.

Maybe.  I renamed "project.pbproj" -> "SDL_gfx.xcodeproj".  Finder now knows XCode is the default program to open this kind of file.  However, there must be something internal to the file that throws off Leopard: Finder sees the file as type "Document", while other .xcodeproj files are seen as kind "XCode Project File".  In any case, the renamed file is loaded into XCode as a text file - not the desired behavior.  I suspect xcodeproj files are internally built as xml/plist type databases, and the older version is lacking some nodes that XCode 3.1+ needs.

I then attempted using marabus' version, and ran into many more problems.  1) This particular project file is closely tuned to marabus' personal file storage system, and wasn't able to find any of the sources in SDL_gfx-2.0.22 when i moved it there.  2) It wouldn't work for me, since it is hard-coded to build for 64 bits and 10.6, neither of which are available on my wife's Mini.  3)  After i corrected for the above as well as i could, the build errors out with:
_SDL_framerateDelay in SDL_framerate.o
symbols not found

SDL_framerate.o does exist, and i'm not really sure at this point what else to look at. 

[SupSuper]

Funny, Xcode's supposed to be backwards-compatible from what I read. Maybe it was the other PB project. Guess it doesn't matter.

I will investigate that reading closer, thank you.  However, i question the wisdom of relying upon a dependency as dodgy as this, but of course that's all up to SupSuper!

If I knew of a better solution I would use it.

[SupSuper]

I contacted the SDL_gfx author about it, he knows the included XCode project is outdated since it was sent in by contributors long ago. However if you have an updated working project you can send him and he'll add it to the next build.

Also:

I do have a Mac, but usually build SDL_gfx via autoconf (configure/make) - presumably this works, since I have fink/macports installed.

[luciderous]

I'm glad to announce that this thread is now officially obsolete and recommend it to be deleted altogether.
Here is a new champion - https://openxcom.ninex.info/forum/index.php?topic=127.0
 

[Dentrassi_BBQ]

So we're already not supporting Tiger, and now you want to drop support for Leopard, as well?  That's about two fifths of all Macs that can't afford the latest and greatest...  Could we please make this project a little more elitist?

[luciderous]

Dentrassi_BBQ, not to make an argument or anything, but the compilation guide is made the way it is because that's the software I personally use. So unless you are eager to contribute to the project by building it on your platform and your way, it can't be helped.
And as I noticed earlier, the step-by-step instructions should be the same for prior Mac OS X versions as well, with minor changes in build parameters that would be obvious to anyone at least distantly aquainted with Xcode. If you won't compile it yourself, there is a prebuilt binary that DOES (or at least should) work on 10.5 Leopard. Hope that clears any misunderstanding.

[Dentrassi_BBQ]

Look, i really want to work with you on this, but Freeciv is ramping up right now for a new unstable release, and a new stable release right behind it.  After that i need to focus on semester finals.  I should have more time around the end of December.

That being said, it is one thing to start a new topic called "Compiling on Mac OS X Snow Leopard..." and entirely something else when you ask that the more inclusive topic about compiling for OSX be deleted.  That implies that users who don't have SL shouldn't even be able to access the information that has previously been put together for them.  Please inform me how i misunderstood that.

I will give your binary another go.  Last time i tried, it was looking for dependencies in some obscure directory like /usr/local/Cellar/ , which i assume only exists on your particular setup.

[luciderous]

That implies that users who don't have SL shouldn't even be able to access the information that has previously been put together for them.

Well, that would be true if the original guide did contain the info on the build process for legacy OSX versions. And had you been thorough on reading it, as well as reading the new guide - there would be no impied meanings for you. You would clearly see that the new guide is simly a simlification of the old one, a cleaning of the mess, to be precise. I use the same SDK, same Deployment Targets. Nothing else changes.
However, if you think that the original guide will be of any real help to you, despite my explanation - be my guest, if you don't want me to make your life easier, than who am I to deny you the opportunity to get your hands dirty? 

[Dentrassi_BBQ]

I'm having another go at this, but still having problems.  I have installed the framework versions of SDL and SDL_mixer [in /Library/Frameworks/].  Now when i go to build SDL_gfx it claims that SDL isn't installed.  Before i dump the frameworks and build SDL from scratch, is there something else i should try?