#8879 closed patch
XCode project
| Reported by: | SF/jweinberg | Owned by: | fingolfin |
|---|---|---|---|
| Priority: | normal | Component: | Port: Mac OS X |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
This is the xcode project that I assembled. Requires the SDL.Framework to be dropped into ~/Library/Frameworks.
Ticket imported from: #1988502. Ticket imported from: patches/984.
Attachments (1)
Change History (12)
by , 16 years ago
| Attachment: | xcode_proj.diff.gz added |
|---|
comment:1 by , 16 years ago
This is not a bug report, but rather a patch. Moving to the patch tracker.
comment:2 by , 16 years ago
OK, I don't have a mac here, so I can only eyeball review this, but that's enough for already quite some remarks ;)
* Doing #elif defined(UNIX) || defined(XCODE) or #if defined(UNIX) || defined(MACOSX) is not correct! Rather, when building on Mac OS X, the UNIX #define must be set. You should be able to do that within the XCode project, either by tweaking the build setting, or by using a prefix file included for *all* source files. This will make it unnecessary to tweak scummsys.h and many other files.
* You added a new Info.plist template, which contains this: <string>com.yourcompany.${PRODUCT_NAME:identifier}</string> which certainly is incorrect. Note that we already ship an Info.plist template! Best would be to use that! That should be possible with some tweaking (you might need to add a script phase to the build process of your project file for it). If you can't figure that out, at least make sure that this new Info.plis matches our existing one.
* Also, ideally it should be possible to build with Vorbis, MP3 etc. support, else the binaries produced with your project are not that useful ;).
* For this and other reasons, it is important to replicate some more stuff from config.h in your global prefix header file, e.g.
#define HAVE_X86 (only if building on intel, of curse) #define USE_VORBIS #define USE_FLAC #define USE_MAD #define USE_ZLIB #define USE_MPEG2 #define USE_MT32EMU
* Keeping all this up-to-date as we enhance and change ScummVM's main build system might become tiresome, though. On the long run it might be better to enhance your project file to invoke ScummVM's configure script to generate a correct config.h (this might require some tweaking to configure, but shouldn't be too hard).
comment:3 by , 16 years ago
| Owner: | set to |
|---|
comment:4 by , 16 years ago
Well aware of the missing stuff.
As for the XCODE defines, the reason for doing this was because the way your UNIX defines are set up it specifies using the Unix SDL build. In an effort to make it a standard XCode build process, including being able to build a fat binary without jumping through all the hoops. This means I also need to use the built in build system. Yes, I can make an XCode project that uses the conifgure/makefile path, but this isn't normal for a mac build. All the libraries where going to be added once I get them ready, they wern't on the top of my todo list for this, and figured this would be ok for the time being.
If it is your desire for me to just make it a wrapper for the Makefile, so be it, but I feel like it should be a native build, which will allow for many things to work more properly, including the ability to set up the main menu bar with various options (SDLMain.m allows to force a Nib to be loaded with the SDL scene inside). This way we can integrate Scumm within the system and still allow for everything to be in the normal spots.
Let me know....
comment:5 by , 16 years ago
There are some things to clear up here... :)
Using "configure" does *not* imply using our default build system. It is very well possible to run configure and still use the xcode build system for the rest. Which is what my first comment meant to suggest, but I should have stated it so more explicitly.
Note also that for being able to use .nib, it is not necessary to use XCode -- we could easily use a .nib already. The purpose of SDLMain.m (which as you may have noticed I am co-author of ;) originally was to make it possible to work *without* a .nib -- in the very first SDL versions of OS X, people were force to add a .nib, which made it very tedious to get things quickly ported. Now it is as it should be: If you want, you can make a .nib, but you are not forced to.
Currently, we deliberatly chose not to make a custom .nib and not try to hook into the system more. In particular, we do not want "native" conversions of the launcher/global options dialogs etc., for examples (and in this regard follow many popular and portable games out there, like all the Blizzard games including Diablo, WarCraft III, WoW, and others). The main reasons for this are portability and maintainability. It's just far too much effort to maintain two copies of everything (let alone a dozen, for each port).
comment:6 by , 16 years ago
I understand where you're coming from with the Nib and I agree there. But even they all hook up some base functionality throught the menu bar, (Full screen is one that comes to mind). I will look into using the config script when I get a chance.
I knew I had seen your name somewhere before :)
I am still fairly new to OSX, had a mac for just over a year, and been developing on it for a fraction of that time. Thanks for guiding me instead of pushing me one way or the other ;)
comment:7 by , 15 years ago
| Status: | new → pending |
|---|
comment:9 by , 15 years ago
| Status: | pending → closed |
|---|
comment:10 by , 15 years ago
This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).
comment:11 by , 5 years ago
| Component: | → Port: Mac OS X |
|---|
XCode Project