Re: [Warzone-dev] Thinking about a Mac universal binary
On 4/18/07, Giel van Schijndel [EMAIL PROTECTED] wrote:
Dennis Schridde schreef:
Am Mittwoch, 18. April 2007 schrieb Ari Johnson:
Good catch. I forgot to remove the .svn subdirectories from the data.
You can use the `svn export` command to do this for you.
It still exports Makefile.{am,raw} but that's not so bad. I didn't
realize that svn export could do a subdirectory so easily, which is
silly since I did realize that svn treats everything in your
repository as a subdirectory. Thanks for the pointer.
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Thinking about a Mac universal binary
Am Mittwoch, 18. April 2007 schrieb Ari Johnson: As of my last commit tonight, we have a universal binary of Warzone. I have 54MB DMG file available for anyone who wants to try it, or we can host it as a beta on our site. Why is this __54__ MB big??? Is the data doubled? I can't believe that the binaries+libs for x86 take ~30MB... --Dennis signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Thinking about a Mac universal binary
On 4/18/07, Dennis Schridde [EMAIL PROTECTED] wrote: Am Mittwoch, 18. April 2007 schrieb Ari Johnson: As of my last commit tonight, we have a universal binary of Warzone. I have 54MB DMG file available for anyone who wants to try it, or we can host it as a beta on our site. Why is this __54__ MB big??? Is the data doubled? I can't believe that the binaries+libs for x86 take ~30MB... Good catch. I forgot to remove the .svn subdirectories from the data. It's now a 27MB DMG file. :) Ari ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Thinking about a Mac universal binary
Am Mittwoch, 18. April 2007 schrieb Ari Johnson: On 4/18/07, Dennis Schridde [EMAIL PROTECTED] wrote: Am Mittwoch, 18. April 2007 schrieb Ari Johnson: As of my last commit tonight, we have a universal binary of Warzone. I have 54MB DMG file available for anyone who wants to try it, or we can host it as a beta on our site. Why is this __54__ MB big??? Is the data doubled? I can't believe that the binaries+libs for x86 take ~30MB... Good catch. I forgot to remove the .svn subdirectories from the data. It's now a 27MB DMG file. :) Mirrored at http://download.gna.org/warzone/snapshots/warzone2100-20070418.dmg signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Thinking about a Mac universal binary
On 4/17/07, Ari Johnson [EMAIL PROTECTED] wrote: One thought I had was whether or not to create a branch for the Mac port. I really would not recommend this. It is a lot of work. It gives people the wrong impression. 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. CMake would solve this. But I am repeating myself... The next (and I think the only remaining) step will be to get network play working, both between Macs and from Mac to Linux or Windows. Then I can finally play against you guys. :) Neat :-) - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Thinking about a Mac universal binary
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... --Dennis signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Thinking about a Mac universal binary
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. Thoughts on this, anyone? Otherwise, once I see the commit to remove jpeg support, I'll continue my work and hopefully have a universal binary to send out. Note that I am not going to backport this work to the 2.0.x branch, and that I have so far not made any effort to get it to run on MacOS prior to 10.4/Tiger. I could probably get the Xcode project set up to build it against the earlier SDK for the PPC half, but I don't know how that would work since OpenAL is not part of the pre-10.4 SDK. I will definitely check into this, since the game runs well on G4 and probably earlier processors as it is, and it'd be nice to have it available for all Mac users, not just Tiger people. The next (and I think the only remaining) step will be to get network play working, both between Macs and from Mac to Linux or Windows. Then I can finally play against you guys. :) Ari ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Thinking about a Mac universal binary
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
Re: [Warzone-dev] Thinking about a Mac universal binary
As of my last commit tonight, we have a universal binary of Warzone. I have 54MB DMG file available for anyone who wants to try it, or we can host it as a beta on our site. http://hermes.theari.com/~ari/warzone.dmg I don't have an Intel Mac to test it on. Hopefully someone who does can let me know if it works at all. :) Ari ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Thinking about a Mac universal binary
On 4/17/07, Ari Johnson [EMAIL PROTECTED] wrote: As of my last commit tonight, we have a universal binary of Warzone. I have 54MB DMG file available for anyone who wants to try it, or we can host it as a beta on our site. http://hermes.theari.com/~ari/warzone.dmg I don't have an Intel Mac to test it on. Hopefully someone who does can let me know if it works at all. :) On a side note, there are at least two things left to do: 1. Automatic DMG-building script to make life slightly easier (I decided not to do this from inside Xcode at this point) 2. Either distribute processed Yacc files or add a step to the Xcode project to make sure that a recent enough copy of bison is available to use; right now it's using a copy of bison that I manually installed on my system, but ideally someone could get a fresh Mac, install Xcode on it, download our latest subversion sources, and compile our code without any other steps necessary. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Thinking about a Mac universal binary
On 4/14/07, Ari Johnson [EMAIL PROTECTED] wrote: 1. OpenAL. MacOS X 10.4 provides an OpenAL framework, which I use in building Warzone. I just include the framework in the .app file that gets built, so that it will run on 10.3. But this is probably bad practice. And 10.4 is required for a universal binary anyhow. It's possible to build one that will work on 10.3 and 10.4, but it's a royal hassle. So we can kill off support for OSX prior to 10.4 Tiger ... and probably not that many people would really notice, especially given that most of the bugs the Mac port has are from people who are running on 10.4 boxes with Intel chips anyhow. Let's do that for 2.1. By the time we release 2.1, most people will probably be running MacOSX 10.6 anyway ;-) 2. Other external libraries. Currently, I compile the Mac port by using DarwinPorts to install automake, jpeg, libmad, libogg, libpng, libsdl, libsdl_net, libvorbis, and physfs. You won't need automake for binaries, and libjpeg and libpng are already installed on 10.4 as unix type shared libraries, IIRC. That leaves libmad, libogg, libsdl, libsdl_net, libvorbis and physfs. I think you can safely skip libmad, because people should use the ogg files anyway. The SDL and ogg stuff are probably available as frameworks somewhere. That should leaves physfs. Doesn't it already have an Xcode project? Its maintainer is a Mac-fan, so it would surprise me if it doesn't. Sorry, don't have time to google these myself, but it looks doable to me. BTW, with the CMake build system you can automatically generate a ready to run Xcode project file. - Per ___ Warzone-dev mailing list [EMAIL PROTECTED] https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Thinking about a Mac universal binary
Am Sonntag, 15. April 2007 schrieb Per Inge Mathisen: On 4/14/07, Ari Johnson [EMAIL PROTECTED] wrote: 1. OpenAL. MacOS X 10.4 provides an OpenAL framework, which I use in building Warzone. I just include the framework in the .app file that gets built, so that it will run on 10.3. But this is probably bad practice. And 10.4 is required for a universal binary anyhow. It's possible to build one that will work on 10.3 and 10.4, but it's a royal hassle. So we can kill off support for OSX prior to 10.4 Tiger ... and probably not that many people would really notice, especially given that most of the bugs the Mac port has are from people who are running on 10.4 boxes with Intel chips anyhow. Let's do that for 2.1. By the time we release 2.1, most people will probably be running MacOSX 10.6 anyway ;-) 2. Other external libraries. Currently, I compile the Mac port by using DarwinPorts to install automake, jpeg, libmad, libogg, libpng, libsdl, libsdl_net, libvorbis, and physfs. You won't need automake for binaries, and libjpeg and libpng are already installed on 10.4 as unix type shared libraries, IIRC. That leaves libmad, libogg, libsdl, libsdl_net, libvorbis and physfs. I think you can safely skip libmad, because people should use the ogg files anyway. The SDL and ogg stuff are probably available as frameworks somewhere. That should leaves physfs. Doesn't it already have an Xcode project? Its maintainer is a Mac-fan, so it would surprise me if it doesn't. Sorry, don't have time to google these myself, but it looks doable to me. Icculus switched over to CMake for the trunk not too long ago, so PhysFS 1.1.1 has XCode support. I don't know what he plans for 1.0, though. --Dennis signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list [EMAIL PROTECTED] https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Thinking about a Mac universal binary
On 4/15/07, Dennis Schridde [EMAIL PROTECTED] wrote: Am Sonntag, 15. April 2007 schrieb Per Inge Mathisen: On 4/14/07, Ari Johnson [EMAIL PROTECTED] wrote: 1. OpenAL. MacOS X 10.4 provides an OpenAL framework, which I use in building Warzone. I just include the framework in the .app file that gets built, so that it will run on 10.3. But this is probably bad practice. And 10.4 is required for a universal binary anyhow. It's possible to build one that will work on 10.3 and 10.4, but it's a royal hassle. So we can kill off support for OSX prior to 10.4 Tiger ... and probably not that many people would really notice, especially given that most of the bugs the Mac port has are from people who are running on 10.4 boxes with Intel chips anyhow. Let's do that for 2.1. By the time we release 2.1, most people will probably be running MacOSX 10.6 anyway ;-) 2. Other external libraries. Currently, I compile the Mac port by using DarwinPorts to install automake, jpeg, libmad, libogg, libpng, libsdl, libsdl_net, libvorbis, and physfs. You won't need automake for binaries, and libjpeg and libpng are already installed on 10.4 as unix type shared libraries, IIRC. That leaves libmad, libogg, libsdl, libsdl_net, libvorbis and physfs. I think you can safely skip libmad, because people should use the ogg files anyway. The SDL and ogg stuff are probably available as frameworks somewhere. That should leaves physfs. Doesn't it already have an Xcode project? Its maintainer is a Mac-fan, so it would surprise me if it doesn't. Sorry, don't have time to google these myself, but it looks doable to me. Icculus switched over to CMake for the trunk not too long ago, so PhysFS 1.1.1 has XCode support. I don't know what he plans for 1.0, though. PhysFS 1.0.0 doesn't, but I made a project file easily enough. My 10.4 system actually doesn't have libpng or libjpeg, and even if it did most of the libraries that come installed without installing the developer tools are ppc-only so that doesn't help toward a universal binary. Anyhow, I am working on an Xcode project to do all of this. Right now, with the versions of the external libraries I have been using for Warzone, it compiles all of them fine and then tries to compile Warzone, starting with lib/framework. 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. Ari ___ Warzone-dev mailing list [EMAIL PROTECTED] https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Thinking about a Mac universal binary
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. - Per ___ Warzone-dev mailing list [EMAIL PROTECTED] https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Thinking about a Mac universal binary
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? ;) ___ Warzone-dev mailing list [EMAIL PROTECTED] https://mail.gna.org/listinfo/warzone-dev
