On 4/17/07, Dennis Schridde <[EMAIL PROTECTED]> wrote: > Am Dienstag, 17. April 2007 schrieb Ari Johnson: > > On 4/15/07, Ari Johnson <[EMAIL PROTECTED]> wrote: > > > On 4/15/07, Per Inge Mathisen <[EMAIL PROTECTED]> wrote: > > > > On 4/15/07, Ari Johnson <[EMAIL PROTECTED]> wrote: > > > > > The problem I have right now is > > > > > that a MacOS header file that Xcode is including in some bizarre > > > > > chain cause keyDown and mouseDown to be defined as enum values, > > > > > whereas we define them as functions. Would it be a crime against > > > > > nature to rename our functions to work around this? I can try to > > > > > figure out how to un-include the offending header file, if so. > > > > > > > > Feel free to rename if you need. > > > > > > > > You might just find it difficult to un-include the header file. Apple, > > > > in its infinite wisdom, apparently decided all projects should > > > > automatically include some Carbon headers in every project compiled in > > > > Xcode, and I haven't found a way to disable that nonsense. > > > > > > I could have told it to do a Legacy Framework instead of Carbon > > > Framework, but where's the fun in that? ;) > > > > Other than waiting on jpeg to be removed (I could make a framework for > > jpeg but since I'd just have to remove it later I'm not going to do > > that) I think I'm pretty close on this project. This means good > > things: > > 1. Universal binary > > 2. Better creation of .app bundle > > 3. Easier build process for the Mac (absolutely no need to > > download/install external libraries; just type 'xcodebuild' and play > > the game) > > 4. Easier for Mac developers to get involved in the project > > > > One thought I had was whether or not to create a branch for the Mac > > port. It's not that much stuff to integrate into the main trunk, the > > real concern is just that future changes in the code won't get > > reflected right away in the Xcode project file. This would mainly > > come up if we added files or changed the minimum version of an > > external library that we depend on. > Sorry, I don't understand this. > Why do you want to have a branch? > Because in the trunk we might remove files which your Xcode project file would > try to build? That happens to the MSVC project file, too...
Either adding or removing files, yes. I suppose that it is easy enough to fix any time that someone builds the Mac version for distribution. I don't wish to use CMake because I don't know how it will handle external library dependencies. I have the Xcode project set up to download, md5sum, unpack, and build a framework for each of the libraries we depend on, and then include those frameworks in the final application bundle. This works and everything that's needed is available if you have Xcode, a component of OSX, installed. Wouldn't using cmake require both: 1. The person building the application to have cmake installed 2. Cmake files to be added to our build system anyhow ? At any rate, it works so far. The most important thing is getting a universal binary out there for all Mac users to heavily test. Ari _______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
