Re: [Warzone-dev] [Warzone 2100 Trac] #64: FMV playback code --Testing needed, especially on MACS!
bugs buggy wrote: On 9/14/08, Tim Baumgartner [EMAIL PROTECTED] wrote: Nice work :) I tested on Linux (if you can wait about a week I can test it out on OS X) and only had a problem with the directory names in the extracted sequences directory. I had to lowercase the first letters in the directories data/base/sequences/Cam1, Cam2, and Cam3 so that they are 'cam1', 'cam2', 'cam3' in order for my machine to find and load the mission videos. Other than that, my only complaint is that the video quality is pretty low. Tim Not to sound too pushy, but is it possible to explain to others how to add the Theora dependency ? We got some more mac people wanting to test things out, but nobody has a clue how to fix the xcode stuff to make this patch work correctly. For the low video quality, I added a menu option of 'native', so it will display it centered on your screen in its native resolution, which makes it look better. Other than redoing all the videos from scratch, we have to live with the 320x240 192x168 videos we got now. I'll try to get the patch (is it still a patch or had it made it to the trunk yet?) working on OS X in the next few days and post the patch of the Xcode project. I meant to test it over the weekend but I've been busy with other obligations... Tim ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Backporting Xcode Project Updates to 2.1 Branch
Giel van Schijndel wrote: Tim Baumgartner schreef: Are there any objections to me porting the Xcode project file fixes in trunk over to 2.1 branch? No objections from me, seems like a good idea. The updates have been ported over to 2.1 branch so Warzone should build on Tiger and Leopard without any problems in both 2.1 branch and trunk. Tim ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Backporting Xcode Project Updates to 2.1 Branch
Ari Johnson wrote: On Wed, Sep 3, 2008 at 4:22 PM, Giel van Schijndel [EMAIL PROTECTED] wrote: Tim Baumgartner schreef: Giel van Schijndel wrote: Tim Baumgartner schreef: Are there any objections to me porting the Xcode project file fixes in trunk over to 2.1 branch? No objections from me, seems like a good idea. The updates have been ported over to 2.1 branch so Warzone should build on Tiger and Leopard without any problems in both 2.1 branch and trunk. Should build? Did you test it? It does build on Tiger. Both 2.1 and trunk tested. I tested it pretty thoroughly on my system but I can't be sure it works on all systems. ;) Tim ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] ChangeLog
Dennis Schridde wrote: Hi! I think the ChangeLog should be updated again. Changes I would like to see in it are the bugfixes by Buginator, the recent buildsystem changes for XCode, AI fixes, etc. Maybe we can also remember to update it immediately, so we wont get into trouble having to search for all relevant changes in the commit log. Should a new section be added to Changelog (e.g. trunk for the trunk changelog or 2.1 branch for the 2.1 branch changelog) for the updates? Is there any kind of procedure that I need to follow for updating the changelog or can I just update to my heart's content? Tim ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Backporting Xcode Project Updates to 2.1 Branch
Are there any objections to me porting the Xcode project file fixes in trunk over to 2.1 branch? Tim ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r5877 - /trunk/macosx/Warzone.xcodeproj/project.pbxproj
Tim Baumgartner wrote: Ari Johnson wrote: On Thu, Aug 28, 2008 at 12:40 AM, Tim Baumgartner [EMAIL PROTECTED] wrote: Ari Johnson wrote: On Wed, Aug 27, 2008 at 7:38 PM, Tim Baumgartner [EMAIL PROTECTED] wrote: Tim Baumgartner wrote: Ari Johnson wrote: On Tue, Aug 26, 2008 at 10:36 AM, Freddie Witherden [EMAIL PROTECTED] wrote: Hi Ari, Tim, Good news about the Xcode project! However, do you know if it is possible to comment out a target for 10.5 (which ships with Bison 2.3)? So far as 10.5 goes, trunk builds (with a slight modification to multiint.c IIRC). I don't have 10.5. There would, however, be more than just leaving out the Bison target required to make it work on both 10.4 and 10.5 with its included copy of Bison. A more likely solution would be for the Bison target to do the following: 1. If the installed Bison is not 2.3 or better, fetch and build Bison 2.3. 2. No matter what, create a wrapper script that will call Bison 2.3, whether it was built in step 1 or not. Then the Xcode project can point to the wrapper script for its build rules. Ari, thanks for committing the Bison patch. A quick Google search led me to a page (http://www.mail-archive.com/[EMAIL PROTECTED]/msg01100.html) that claims the location of the Bison distribution files can be set with the env var BISON_PKGDATADIR but a configure flag might be better (I'll look into it). The Bison wrapper script sounds like a good idea and I don't see any reason why it shouldn't be implemented as Ari suggested. I'll work on this tomorrow (Wednesday) and post back to this thread with the details of the final script and Xcode project setup. Alright, I have a patch that downloads Bison only if needed and that adds a Bison wrapper script (located at 'macosx/external/bison.sh'). The patch is attached and I would appreciate it if someone else could test the patch to make sure there are no problems on other systems and to give me some feedback before I commit it. The script determines the version of Bison by parsing the version value from the output of the --version paramter. If the version of Bison on the system is older than a minimum version (currently 1.31) or if it is blacklisted (although none currently are), the build process will attempt to download and build Bison 2.3. To simplify things, if a binary in macosx/external/bison/ exists, this version is used regardless. During the build process, instead of calling Bison directly, bison.sh is called. If a Bison binary exists in an expected location inside of macosx/external/bison/, it is used. Otherwise, the command 'bison' is executed. Tim I had to manually set it executable, but that's just because it didn't come to me through svn, I'm sure. I forgot that I have a bison 2.3 installed on my system, and bison.sh found that after I removed external/bison and built Warzone successfully. Removing that version causes bison.sh to download and build bison just fine. So only the m4sugar issue seems to remain. Awesome. :) Good to hear it's working properly :) If no one has any objections by tomorrow (Thursday) evening, I'll commit the smarter Bison patch to trunk. I'm thinking that the m4sugar problem is due to Bison not being make installed when the Xcode project builds it so it isn't able to find its needed supporting files (unless Bison 2.3 is already installed on the system, then it just uses those supporting files). If this is the problem, it could be easily fixed by a './configure --prefix /path/macosx/external/bison/bin/' and by then calling 'make install' within the Bison build script. I should be able to work on a fix or investigate the problem some more in the next couple of days. Tim Actually, I think giving it a PKG_DATADIR or whatever the variable it uses to compile in the path to its files would be sufficient, without having to run 'make install.' The only thing that worries me about that is that the location of the supporting files in the source might be moved in future Bison releases or they might be scattered in the current one (if more files than just m4sugar are needed). 'make install' should always put any supporting files in their correct location so we shouldn't have to worry about them at all. Either way wouldn't be hard to implement but I feel that the 'make install' method would be a little safer and might save some headaches in the future. Alright, hopefully the m4sugar problem should be solved in the trunk as of r5887. Bison is now properly installed to a directory (built) in the Bison source directory and the bison.sh script has been updated with the new binary location. Tim ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r5877 - /trunk/macosx/Warzone.xcodeproj/project.pbxproj
Ari Johnson wrote: On Wed, Aug 27, 2008 at 7:38 PM, Tim Baumgartner [EMAIL PROTECTED] wrote: Tim Baumgartner wrote: Ari Johnson wrote: On Tue, Aug 26, 2008 at 10:36 AM, Freddie Witherden [EMAIL PROTECTED] wrote: Hi Ari, Tim, Good news about the Xcode project! However, do you know if it is possible to comment out a target for 10.5 (which ships with Bison 2.3)? So far as 10.5 goes, trunk builds (with a slight modification to multiint.c IIRC). I don't have 10.5. There would, however, be more than just leaving out the Bison target required to make it work on both 10.4 and 10.5 with its included copy of Bison. A more likely solution would be for the Bison target to do the following: 1. If the installed Bison is not 2.3 or better, fetch and build Bison 2.3. 2. No matter what, create a wrapper script that will call Bison 2.3, whether it was built in step 1 or not. Then the Xcode project can point to the wrapper script for its build rules. Ari, thanks for committing the Bison patch. A quick Google search led me to a page (http://www.mail-archive.com/[EMAIL PROTECTED]/msg01100.html) that claims the location of the Bison distribution files can be set with the env var BISON_PKGDATADIR but a configure flag might be better (I'll look into it). The Bison wrapper script sounds like a good idea and I don't see any reason why it shouldn't be implemented as Ari suggested. I'll work on this tomorrow (Wednesday) and post back to this thread with the details of the final script and Xcode project setup. Alright, I have a patch that downloads Bison only if needed and that adds a Bison wrapper script (located at 'macosx/external/bison.sh'). The patch is attached and I would appreciate it if someone else could test the patch to make sure there are no problems on other systems and to give me some feedback before I commit it. The script determines the version of Bison by parsing the version value from the output of the --version paramter. If the version of Bison on the system is older than a minimum version (currently 1.31) or if it is blacklisted (although none currently are), the build process will attempt to download and build Bison 2.3. To simplify things, if a binary in macosx/external/bison/ exists, this version is used regardless. During the build process, instead of calling Bison directly, bison.sh is called. If a Bison binary exists in an expected location inside of macosx/external/bison/, it is used. Otherwise, the command 'bison' is executed. Tim I had to manually set it executable, but that's just because it didn't come to me through svn, I'm sure. I forgot that I have a bison 2.3 installed on my system, and bison.sh found that after I removed external/bison and built Warzone successfully. Removing that version causes bison.sh to download and build bison just fine. So only the m4sugar issue seems to remain. Awesome. :) Good to hear it's working properly :) If no one has any objections by tomorrow (Thursday) evening, I'll commit the smarter Bison patch to trunk. I'm thinking that the m4sugar problem is due to Bison not being make installed when the Xcode project builds it so it isn't able to find its needed supporting files (unless Bison 2.3 is already installed on the system, then it just uses those supporting files). If this is the problem, it could be easily fixed by a './configure --prefix /path/macosx/external/bison/bin/' and by then calling 'make install' within the Bison build script. I should be able to work on a fix or investigate the problem some more in the next couple of days. Tim ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r5877 - /trunk/macosx/Warzone.xcodeproj/project.pbxproj
Ari Johnson wrote: On Thu, Aug 28, 2008 at 12:40 AM, Tim Baumgartner [EMAIL PROTECTED] wrote: Ari Johnson wrote: On Wed, Aug 27, 2008 at 7:38 PM, Tim Baumgartner [EMAIL PROTECTED] wrote: Tim Baumgartner wrote: Ari Johnson wrote: On Tue, Aug 26, 2008 at 10:36 AM, Freddie Witherden [EMAIL PROTECTED] wrote: Hi Ari, Tim, Good news about the Xcode project! However, do you know if it is possible to comment out a target for 10.5 (which ships with Bison 2.3)? So far as 10.5 goes, trunk builds (with a slight modification to multiint.c IIRC). I don't have 10.5. There would, however, be more than just leaving out the Bison target required to make it work on both 10.4 and 10.5 with its included copy of Bison. A more likely solution would be for the Bison target to do the following: 1. If the installed Bison is not 2.3 or better, fetch and build Bison 2.3. 2. No matter what, create a wrapper script that will call Bison 2.3, whether it was built in step 1 or not. Then the Xcode project can point to the wrapper script for its build rules. Ari, thanks for committing the Bison patch. A quick Google search led me to a page (http://www.mail-archive.com/[EMAIL PROTECTED]/msg01100.html) that claims the location of the Bison distribution files can be set with the env var BISON_PKGDATADIR but a configure flag might be better (I'll look into it). The Bison wrapper script sounds like a good idea and I don't see any reason why it shouldn't be implemented as Ari suggested. I'll work on this tomorrow (Wednesday) and post back to this thread with the details of the final script and Xcode project setup. Alright, I have a patch that downloads Bison only if needed and that adds a Bison wrapper script (located at 'macosx/external/bison.sh'). The patch is attached and I would appreciate it if someone else could test the patch to make sure there are no problems on other systems and to give me some feedback before I commit it. The script determines the version of Bison by parsing the version value from the output of the --version paramter. If the version of Bison on the system is older than a minimum version (currently 1.31) or if it is blacklisted (although none currently are), the build process will attempt to download and build Bison 2.3. To simplify things, if a binary in macosx/external/bison/ exists, this version is used regardless. During the build process, instead of calling Bison directly, bison.sh is called. If a Bison binary exists in an expected location inside of macosx/external/bison/, it is used. Otherwise, the command 'bison' is executed. Tim I had to manually set it executable, but that's just because it didn't come to me through svn, I'm sure. I forgot that I have a bison 2.3 installed on my system, and bison.sh found that after I removed external/bison and built Warzone successfully. Removing that version causes bison.sh to download and build bison just fine. So only the m4sugar issue seems to remain. Awesome. :) Good to hear it's working properly :) If no one has any objections by tomorrow (Thursday) evening, I'll commit the smarter Bison patch to trunk. I'm thinking that the m4sugar problem is due to Bison not being make installed when the Xcode project builds it so it isn't able to find its needed supporting files (unless Bison 2.3 is already installed on the system, then it just uses those supporting files). If this is the problem, it could be easily fixed by a './configure --prefix /path/macosx/external/bison/bin/' and by then calling 'make install' within the Bison build script. I should be able to work on a fix or investigate the problem some more in the next couple of days. Tim Actually, I think giving it a PKG_DATADIR or whatever the variable it uses to compile in the path to its files would be sufficient, without having to run 'make install.' The only thing that worries me about that is that the location of the supporting files in the source might be moved in future Bison releases or they might be scattered in the current one (if more files than just m4sugar are needed). 'make install' should always put any supporting files in their correct location so we shouldn't have to worry about them at all. Either way wouldn't be hard to implement but I feel that the 'make install' method would be a little safer and might save some headaches in the future. Tim ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r5877 - /trunk/macosx/Warzone.xcodeproj/project.pbxproj
Ari Johnson wrote: On Tue, Aug 26, 2008 at 10:36 AM, Freddie Witherden [EMAIL PROTECTED] wrote: Hi Ari, Tim, Good news about the Xcode project! However, do you know if it is possible to comment out a target for 10.5 (which ships with Bison 2.3)? So far as 10.5 goes, trunk builds (with a slight modification to multiint.c IIRC). I don't have 10.5. There would, however, be more than just leaving out the Bison target required to make it work on both 10.4 and 10.5 with its included copy of Bison. A more likely solution would be for the Bison target to do the following: 1. If the installed Bison is not 2.3 or better, fetch and build Bison 2.3. 2. No matter what, create a wrapper script that will call Bison 2.3, whether it was built in step 1 or not. Then the Xcode project can point to the wrapper script for its build rules. Ari, thanks for committing the Bison patch. A quick Google search led me to a page (http://www.mail-archive.com/[EMAIL PROTECTED]/msg01100.html) that claims the location of the Bison distribution files can be set with the env var BISON_PKGDATADIR but a configure flag might be better (I'll look into it). The Bison wrapper script sounds like a good idea and I don't see any reason why it shouldn't be implemented as Ari suggested. I'll work on this tomorrow (Wednesday) and post back to this thread with the details of the final script and Xcode project setup. Per was kind enough to grant me commit access to the repository for OS X things so I shouldn't need to bother you all too much about getting OS X patches committed in the future. Tim ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Trunk On OS X
Ari Johnson wrote: On Sat, Aug 23, 2008 at 2:50 PM, Freddie Witherden [EMAIL PROTECTED] wrote: Hi all, I have just got around to compiling off trunk on OS X 10.5. This required two changes: • Updating the QuesoGLC version to trunk r832; • Changing the include path for GLC so that revisions r5833 compile. However, there are several issues which I experience on my Intel MacBook running 10.5: 1. Font rendering is fudged, see http://www.witherden.org/~freddie/wzosx.tiff (non permanent link!). - Might be due to new GLC version; will try older revisions. 2. The game crashes on exit and requires a kill signal. - Suspect OpenAL to be the cause (waiting on a mutex), more debugging needed. 3. No v-sync (it could be due to GPU/OS version), however an option enable v-sync or not would be useful. - Space in Video Options? - Code is: SDL_GL_SetAttribute(SDL_GL_SWAP_CONTROL, 1); - Useful on other operating systems. Does anyone else have any other issues to add to the list (or would like a recent trunk .app, which I can do). The first two should be our priority without a doubt. (Do we have a Mac maintainer?) I call not it! :P It sounds like you've made some progress. Did you get the project up-to-date so that it is self-contained and requires no external dependencies be installed to either build or run the game? 4. Image bitmap rendering is screwed up (images appear blocky, especially around borders). You can see this a bit in your wzosx.tiff screenshot in the Warzone 2100 logo. I submitted a patch to this ML a few weeks ago that would have the Xcode project automatically download and use a correct version of Bison during the build process but, if I remember correctly, the posting was ignored or nobody wanted to commit it because they couldn't test it or something. I can resubmit the patch if someone is willing to take a look at it. Freddie, try the QuesoGLC release-0.7 branch instead of the trunk revision. I tested it out on Tiger last week and I didn't have any font rendering problems. Tim ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] [bug #12136] OS X Trunk lib/ivis_opengl/screen.c Compile Problems
URL: http://gna.org/bugs/?12136 Summary: OS X Trunk lib/ivis_opengl/screen.c Compile Problems Project: Warzone Resurrection Project Submitted by: baum Submitted on: Saturday 08/02/2008 at 16:46 Category: None Severity: Important Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Release: svn/trunk Operating System: Mac OS Planned Release: None ___ Details: When compiling trunk r5757 on OS X Tiger: trunk/macosx/../lib/ivis_opengl/screen.c: In function 'Init_FBO': trunk/macosx/../lib/ivis_opengl/screen.c:414: warning: the address of 'glGenFramebuffersEXT', will always evaluate as 'true' trunk/macosx/../lib/ivis_opengl/screen.c:453: error: 'GL_FRAMEBUFFER_INCOMPLETE_DUPLICATE_ATTACHMENT_EXT' undeclared (first use in this function) trunk/macosx/../lib/ivis_opengl/screen.c:453: error: (Each undeclared identifier is reported only once trunk/macosx/../lib/ivis_opengl/screen.c:453: error: for each function it appears in.) r5733 caused the problem. ___ Reply to this item at: http://gna.org/bugs/?12136 ___ Message sent via/by Gna! http://gna.org/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.1 Beta 4 OS X Binary
Giel van Schijndel wrote: Tim Baumgartner schreef: The homepage beta 4 release announcement says that the beta 4 OS X binary will be posted on the download page soon. Is someone taking care of this? I can build a beta 4 binary and host it temporarily so it can be copied over to the website if needed. I just don't want OS X users feeling like second class citizens :p Ah, yes, that would be very much appreciated! I built both the release and debug configurations: Release: https://ahead.homelinux.com/misc/warzone2100-2.1_beta4.dmg Debug: https://ahead.homelinux.com/misc/warzone2100-2.1_beta4_debug.dmg (Self-signed and expired SSL cert) The only thing I'm unsure about is whether or not there will be problems if the user running the binary doesn't have X11 installed due to some symlinks to dylibs that the X11 installation creates (https://gna.org/bugs/?11619). I can try removing X11 and the symlinks and building Warzone again if this problem occurs. Otherwise, the binaries ran smoothly on the two systems I tried them on (both had X11, however). Tim ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Patch for Leopard QuesoGLC Linking Problem
Tim Baumgartner wrote: Ari Johnson wrote: On Tue, Jul 22, 2008 at 2:28 PM, Giel van Schijndel [EMAIL PROTECTED] wrote: Tim Baumgartner schreef: Ari Johnson wrote: No. I like it being separate, as long as it is intelligent about deciding whether to actually apply the patch. :) Alright, the Xcode script now looks for the QuesoGLC patch in macosx/external/. The updated Xcode project file patch is attached. Question: did this patch or any variant of it got applied to trunk or 2.1? I'd be happy to apply a patch if necessary, but I haven't got any Macs in my reach to test with, and I'd rather not break the Xcode build system we've got right now. The Xcode build system is, to my knowledge, still broken for trunk because of requirements of a version of Bison that OS X doesn't come with and which nobody has bothered to add to the Xcode system yet. I could be wrong, though. The patch hasn't been applied to the trunk or 2.1 branch. I'll look into adding Bison to the Xcode project but I probably won't be able to do anything until the end of the week or next week. Is anyone able to test this patch and/or apply it? It would bring us one step closer to making the dream of a painless OS X build into a reality ;) Tim ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r5695 - in /trunk: src/ src/Makefile.am src/data.c src/makefile.win32 src/message.c src/message.h src/message_lexer.l src/message_parser.y src/messagely.h warzone21
Giel van Schijndel wrote:
Giel van Schijndel schreef:
Author: muggenhor
Date: Mon Jul 28 23:01:05 2008
New Revision: 5695
URL: http://svn.gna.org/viewcvs/warzone?rev=5695view=rev
Log:
Add a new parser: message_parser which parses research message data in a significantly
different format from the current CSV message format as parsed by
loadViewData (this allows for easier gettext translation)
Added:
trunk/src/message_lexer.l (contents, props changed)
- copied, changed from r5694, trunk/lib/framework/strres_lexer.l
trunk/src/message_parser.y (with props)
trunk/src/messagely.h (with props)
The Xcode project will require an update for this.
Here you go: the attached patch adds src/message_lexer.l, src/message_parser.y,
and src/messagely.h to the Xcode project file.
Tim
Index: macosx/Warzone.xcodeproj/project.pbxproj
===
--- macosx/Warzone.xcodeproj/project.pbxproj(revision 5698)
+++ macosx/Warzone.xcodeproj/project.pbxproj(working copy)
@@ -660,6 +660,9 @@
02F5CC910D149658A2D0 /* system.h in Headers */ = {isa =
PBXBuildFile; fileRef = 02F5CC880D149658A2D0 /* system.h */; };
02F5CCC00D1498A3A2D0 /* Popt.framework in Frameworks */ =
{isa = PBXBuildFile; fileRef = 02F5CC6D0D1494AAA2D0 /* Popt.framework */; };
2234C2A00E2BE18200E7704C /* positiondef.h in Copy frameworks */
= {isa = PBXBuildFile; fileRef = 2234C29F0E2BE18200E7704C /* positiondef.h */;
};
+ 2244463C0E3EB7CB004D0F1F /* message_lexer.l in Sources */ =
{isa = PBXBuildFile; fileRef = 224446390E3EB7CB004D0F1F /* message_lexer.l */;
};
+ 2244463D0E3EB7CB004D0F1F /* message_parser.y in Sources */ =
{isa = PBXBuildFile; fileRef = 2244463A0E3EB7CB004D0F1F /* message_parser.y */;
};
+ 2244463E0E3EB7CB004D0F1F /* messagely.h in Copy frameworks */ =
{isa = PBXBuildFile; fileRef = 2244463B0E3EB7CB004D0F1F /* messagely.h */; };
9742E5730DF9975E000A5D41 /* lexer_input.c in Sources */ = {isa
= PBXBuildFile; fileRef = 9742E5710DF9975E000A5D41 /* lexer_input.c */; };
9742E5740DF9975E000A5D41 /* lexer_input.h in Copy frameworks */
= {isa = PBXBuildFile; fileRef = 9742E5720DF9975E000A5D41 /* lexer_input.h */;
};
9742E5770DF9979C000A5D41 /* parsetest.c in Sources */ = {isa =
PBXBuildFile; fileRef = 9742E5750DF9979C000A5D41 /* parsetest.c */; };
@@ -852,6 +855,7 @@
9742E5740DF9975E000A5D41 /* lexer_input.h in
Copy frameworks */,
9742E5780DF9979C000A5D41 /* parsetest.h in Copy
frameworks */,
2234C2A00E2BE18200E7704C /* positiondef.h in
Copy frameworks */,
+ 2244463E0E3EB7CB004D0F1F /* messagely.h in Copy
frameworks */,
);
name = Copy frameworks;
runOnlyForDeploymentPostprocessing = 0;
@@ -1690,6 +1694,9 @@
02F5CC870D149658A2D0 /* poptparse.c */ = {isa =
PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.c.c; name =
poptparse.c; path = external/popt/poptparse.c; sourceTree = SOURCE_ROOT; };
02F5CC880D149658A2D0 /* system.h */ = {isa =
PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.c.h; name =
system.h; path = external/popt/system.h; sourceTree = SOURCE_ROOT; };
2234C29F0E2BE18200E7704C /* positiondef.h */ = {isa =
PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.c.h; name =
positiondef.h; path = ../src/positiondef.h; sourceTree = SOURCE_ROOT; };
+ 224446390E3EB7CB004D0F1F /* message_lexer.l */ = {isa =
PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.lex; name =
message_lexer.l; path = ../src/message_lexer.l; sourceTree = SOURCE_ROOT; };
+ 2244463A0E3EB7CB004D0F1F /* message_parser.y */ = {isa =
PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.yacc; name
= message_parser.y; path = ../src/message_parser.y; sourceTree = SOURCE_ROOT; };
+ 2244463B0E3EB7CB004D0F1F /* messagely.h */ = {isa =
PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.c.h; name =
messagely.h; path = ../src/messagely.h; sourceTree = SOURCE_ROOT; };
9742E5710DF9975E000A5D41 /* lexer_input.c */ = {isa =
PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.c.c; name =
lexer_input.c; path = ../lib/framework/lexer_input.c; sourceTree = SOURCE_ROOT;
};
9742E5720DF9975E000A5D41 /* lexer_input.h */ = {isa =
PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.c.h; name =
lexer_input.h; path = ../lib/framework/lexer_input.h; sourceTree = SOURCE_ROOT;
};
9742E5750DF9979C000A5D41 /* parsetest.c */ = {isa =
PBXFileReference; fileEncoding = 30;
[Warzone-dev] 2.1 Beta 4 OS X Binary
The homepage beta 4 release announcement says that the beta 4 OS X binary will be posted on the download page soon. Is someone taking care of this? I can build a beta 4 binary and host it temporarily so it can be copied over to the website if needed. I just don't want OS X users feeling like second class citizens :p Tim ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] [bug #12100] script_lexer.l Parse Error
URL: http://gna.org/bugs/?12100 Summary: script_lexer.l Parse Error Project: Warzone Resurrection Project Submitted by: baum Submitted on: Sunday 07/27/2008 at 17:33 Category: Engine: Scripting Severity: Important Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Release: 2.1_beta4 Operating System: Mac OS Planned Release: None ___ Details: When trying to build the 2.1 branch (rev 5684), I receive the following error (using Bison 2.3 on OS X Tiger): warzone_src/branches/2.1/macosx/../lib/script/script_lexer.l:49: error: parse error before 'user_defined' ** BUILD FAILED ** ___ Reply to this item at: http://gna.org/bugs/?12100 ___ Message sent via/by Gna! http://gna.org/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Bug#458275: should warzone2100 (beta) be in Debian testing (and migrate to stable)?
Giel van Schijndel wrote: Paul Wise schreef: On Wed, 2008-07-23 at 01:15 +0200, Giel van Schijndel wrote: Any thoughts on this? Another beta might be a good idea, if it is done quickly. Also, when the final release is done, we can put a warzone2100 backport on backports.org for lenny users to upgrade to. Many people don't know about backports.org though, so that might become a support issue/FAQ for the warzone devs. To all devs (with or without commit access): I would really like this to be an active decision on our part, as opposed to a passive one, where we allow the decision to be made for us due to time passing. I.e. either we decide that we do want our current state of 2.1 to be included in Debian's next stable release, or we decide that we don't want that to happen. As long as that decision is an active one, I can live with both. The only negative impact of this on us I can see is the support/FAQ issue mentioned above by Paul. I think another quick beta would be a good route if 2.1 is currently stable enough and runs well on Debian, otherwise there really isn't a good reason to include it in a stable release (and, yes, I know I'm stating the obvious ;) If there are still some rough edges in Debian 2.1, sticking 2.0.10 in lenny and relegating 2.1 to backports.org might be the better course of action. Tim ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Connection Refused from popts Mirror - OS X
In what has grown into a beast of a bug report (https://gna.org/bugs/index.php?11940), there have been reports of OS X users having problems downloading popt during the build process. Attempting to connect to the URI in the Xcode build script (rpm.net.in domain) results in a connection refused message. I don't know if this is a temporary thing or if rpm.net.in will be refusing HTTP requests permanently (anyone have any idea?). It looks like popt is being hosted on the rpm5.org domain (which can be connected to at the moment) so I've come up with a patch that changes the popts download location from the rpm.net.in domain to http://rpm5.org/files/popt/popt-1.10.4.tar.gz . The patch is here: https://gna.org/bugs/download.php?file_id=4615 (filename xcode_popt_0.diff). Tim ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Patch for Leopard QuesoGLC Linking Problem
Ari Johnson wrote: On Tue, Jul 22, 2008 at 2:28 PM, Giel van Schijndel [EMAIL PROTECTED] wrote: Tim Baumgartner schreef: Ari Johnson wrote: No. I like it being separate, as long as it is intelligent about deciding whether to actually apply the patch. :) Alright, the Xcode script now looks for the QuesoGLC patch in macosx/external/. The updated Xcode project file patch is attached. Question: did this patch or any variant of it got applied to trunk or 2.1? I'd be happy to apply a patch if necessary, but I haven't got any Macs in my reach to test with, and I'd rather not break the Xcode build system we've got right now. The Xcode build system is, to my knowledge, still broken for trunk because of requirements of a version of Bison that OS X doesn't come with and which nobody has bothered to add to the Xcode system yet. I could be wrong, though. The patch hasn't been applied to the trunk or 2.1 branch. I'll look into adding Bison to the Xcode project but I probably won't be able to do anything until the end of the week or next week. Tim ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Patch for Leopard QuesoGLC Linking Problem
Ari Johnson wrote: On Wed, Jul 16, 2008 at 3:33 PM, Tim Baumgartner [EMAIL PROTECTED] wrote: There is a Leopard compile problem (http://gna.org/bugs/?11940) in which QuesoGLC fails to link due to the location of some inline function definitions. I came up with a patch that fixes the issue (and submitted it to the QuesoGLC tracker) but I don't know when the problem will be fixed on the official QuesoGLC version. So that the problem doesn't persist for Leopard users trying to compile the Warzone trunk and/or 2.1 branch, I've modified the Xcode file so that it automatically applies the QuesoGLC patch during compilation. If this solution works for everyone (until QuesoGLC itself is fixed), I've attached both the QuesoGLC and Xcode patches. The script assumes the QuesoGLC patch is located in macosx/Resources/ because I didn't know a better place to put it but the location can easily be changed. My standard procedure would be to commit the patch into /macosx/external/. Also, the patch should probably be applied in the script that extracts the QuesoGLC code into that directory, and only if the extraction takes place. That would avoid multiple applications of the patch, although it would require a rm -rf macosx/external/quesoglc in existing checkouts. Oh, how I'd love for a better way to do it. But that's the best I came up with and it works pretty well, on the whole. :) Ari The script runs right after the script that downloads and extracts QuesoGLC. I put it in a new script build phase so that it would be easier to remove once QuesoGLC fixes the issue on their end but I can put it in the download script if you want. For the actual patching, the script copies the patch from macosx/Resources/ to macosx/external/quesoglc/ and patches it from there. If the patch is in the quesoglc directory, the script assumes QuesoGLC has already been patched and doesn't try to re-patch it. This would alleviate the problem of having to rm -rf the quesoglc directory in existing checkouts. In regards to storing the patch (the one I currently have in macosx/Resources/), you would like for it to be stored in macosx/external/, correct? Tim ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Patch for Leopard QuesoGLC Linking Problem
Ari Johnson wrote: On Wed, Jul 16, 2008 at 4:44 PM, Tim Baumgartner [EMAIL PROTECTED] wrote: Ari Johnson wrote: On Wed, Jul 16, 2008 at 3:33 PM, Tim Baumgartner [EMAIL PROTECTED] wrote: There is a Leopard compile problem (http://gna.org/bugs/?11940) in which QuesoGLC fails to link due to the location of some inline function definitions. I came up with a patch that fixes the issue (and submitted it to the QuesoGLC tracker) but I don't know when the problem will be fixed on the official QuesoGLC version. So that the problem doesn't persist for Leopard users trying to compile the Warzone trunk and/or 2.1 branch, I've modified the Xcode file so that it automatically applies the QuesoGLC patch during compilation. If this solution works for everyone (until QuesoGLC itself is fixed), I've attached both the QuesoGLC and Xcode patches. The script assumes the QuesoGLC patch is located in macosx/Resources/ because I didn't know a better place to put it but the location can easily be changed. My standard procedure would be to commit the patch into /macosx/external/. Also, the patch should probably be applied in the script that extracts the QuesoGLC code into that directory, and only if the extraction takes place. That would avoid multiple applications of the patch, although it would require a rm -rf macosx/external/quesoglc in existing checkouts. Oh, how I'd love for a better way to do it. But that's the best I came up with and it works pretty well, on the whole. :) Ari The script runs right after the script that downloads and extracts QuesoGLC. I put it in a new script build phase so that it would be easier to remove once QuesoGLC fixes the issue on their end but I can put it in the download script if you want. For the actual patching, the script copies the patch from macosx/Resources/ to macosx/external/quesoglc/ and patches it from there. If the patch is in the quesoglc directory, the script assumes QuesoGLC has already been patched and doesn't try to re-patch it. This would alleviate the problem of having to rm -rf the quesoglc directory in existing checkouts. In regards to storing the patch (the one I currently have in macosx/Resources/), you would like for it to be stored in macosx/external/, correct? What you're doing is fine, but I do think that the patch should not be in macosx/Resources/. The reason for this is that the Resources directory is intended for files that will be placed inside the application bundle or framework bundles that are created in the build process. That is, resources for the application rather than resources for the build. That makes sense, I just wanted to clear up a little confusion that I had. Also, do you still prefer for the patching to be applied in the download script? I'll make the changes and post back later today. Tim ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Patch for Leopard QuesoGLC Linking Problem
Ari Johnson wrote: On Wed, Jul 16, 2008 at 5:06 PM, Tim Baumgartner [EMAIL PROTECTED] wrote: Ari Johnson wrote: On Wed, Jul 16, 2008 at 4:44 PM, Tim Baumgartner [EMAIL PROTECTED] wrote: Ari Johnson wrote: On Wed, Jul 16, 2008 at 3:33 PM, Tim Baumgartner [EMAIL PROTECTED] wrote: There is a Leopard compile problem (http://gna.org/bugs/?11940) in which QuesoGLC fails to link due to the location of some inline function definitions. I came up with a patch that fixes the issue (and submitted it to the QuesoGLC tracker) but I don't know when the problem will be fixed on the official QuesoGLC version. So that the problem doesn't persist for Leopard users trying to compile the Warzone trunk and/or 2.1 branch, I've modified the Xcode file so that it automatically applies the QuesoGLC patch during compilation. If this solution works for everyone (until QuesoGLC itself is fixed), I've attached both the QuesoGLC and Xcode patches. The script assumes the QuesoGLC patch is located in macosx/Resources/ because I didn't know a better place to put it but the location can easily be changed. My standard procedure would be to commit the patch into /macosx/external/. Also, the patch should probably be applied in the script that extracts the QuesoGLC code into that directory, and only if the extraction takes place. That would avoid multiple applications of the patch, although it would require a rm -rf macosx/external/quesoglc in existing checkouts. Oh, how I'd love for a better way to do it. But that's the best I came up with and it works pretty well, on the whole. :) Ari The script runs right after the script that downloads and extracts QuesoGLC. I put it in a new script build phase so that it would be easier to remove once QuesoGLC fixes the issue on their end but I can put it in the download script if you want. For the actual patching, the script copies the patch from macosx/Resources/ to macosx/external/quesoglc/ and patches it from there. If the patch is in the quesoglc directory, the script assumes QuesoGLC has already been patched and doesn't try to re-patch it. This would alleviate the problem of having to rm -rf the quesoglc directory in existing checkouts. In regards to storing the patch (the one I currently have in macosx/Resources/), you would like for it to be stored in macosx/external/, correct? What you're doing is fine, but I do think that the patch should not be in macosx/Resources/. The reason for this is that the Resources directory is intended for files that will be placed inside the application bundle or framework bundles that are created in the build process. That is, resources for the application rather than resources for the build. That makes sense, I just wanted to clear up a little confusion that I had. Also, do you still prefer for the patching to be applied in the download script? I'll make the changes and post back later today. No. I like it being separate, as long as it is intelligent about deciding whether to actually apply the patch. :) Alright, the Xcode script now looks for the QuesoGLC patch in macosx/external/. The updated Xcode project file patch is attached. Tim Index: macosx/Warzone.xcodeproj/project.pbxproj === --- macosx/Warzone.xcodeproj/project.pbxproj(revision 5562) +++ macosx/Warzone.xcodeproj/project.pbxproj(working copy) @@ -3171,6 +3171,7 @@ buildConfigurationList = 0223BBD30CFE3D5C0056EF85 /* Build configuration list for PBXNativeTarget QuesoGLC */; buildPhases = ( 0223BBDD0CFE3E290056EF85 /* Fetch source */, + 22E849A80E2E0E8F002591A4 /* Patch */, 02F5CC4F0D148FC3A2D0 /* Create database.c */, 0223BBCC0CFE3D5C0056EF85 /* Headers */, 0223BBCD0CFE3D5C0056EF85 /* Resources */, @@ -3741,6 +3742,20 @@ shellPath = /bin/sh; shellScript = DIRECTORY=\SDL_net-1.2.6\\nOUTDIR=\SDL_net\\nFILENAME=\SDL_net-1.2.6.tar.gz\\nSOURCE=\http://www.libsdl.org/projects/SDL_net/release/SDL_net-1.2.6.tar.gz\\nMD5=\7be5b9ef36129ee187ace96906cd264c\\n\ncd external\n\nif [ -d \$OUTDIR\ ]; then\n echo \$OUTDIR already exists, skipping\\n exit 0\nfi\n\nif [ -d \$DIRECTORY\ ]; then\n echo \$DIRECTORY exists, probably from an earlier failed run\ 2\n exit 1\nfi\n\nif [ ! -r \$FILENAME\ ]; then\n echo \Fetching $SOURCE\\n if ! curl -L -o \$FILENAME\ \$SOURCE\; then\necho \Unable to fetch $SOURCE\ 2\n exit 1\n fi\nfi\n\nHAVEMD5=`md5 \$FILENAME\ | sed -n -e 's/^MD5 (\\(.*\\)) = \\(.*\\)$/\\2/p'`\n\nif [ -z \$HAVEMD5\ ]; then\n echo \Unable to compute md5 for $FILENAME\ 2\n exit 1\nfi\n\nif [ \$HAVEMD5\ != \$MD5\ ]; then\n echo \Md5 does not match for $FILENAME\ 2\n exit 1\nfi\n\nEXTENSION=`echo $FILENAME | sed -e 's
Re: [Warzone-dev] Xcode project
I think I've updated the Xcode project file properly but I've never really used
Xcode before so I'm not 100% sure. lib/framework/treapint.h was removed,
src/positiondef.h was added, and the project builds successfully with the
updated project file.
Tim
Giel van Schijndel wrote:
Due to the changes in r5531 [1], i.e. the addition of src/positiondef.h
and r5544, i.e. the removal of lib/framework/treapint.h, the Xcode
project may require an update.
Thus my request if anyone with access to a Mac would be so kind to
update this.
[1] http://developer.wz2100.net/changeset/5531
[2] http://developer.wz2100.net/changeset/5544
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Index: macosx/Warzone.xcodeproj/project.pbxproj
===
--- macosx/Warzone.xcodeproj/project.pbxproj(revision 5546)
+++ macosx/Warzone.xcodeproj/project.pbxproj(working copy)
@@ -659,6 +659,7 @@
02F5CC900D149658A2D0 /* poptparse.c in Sources */ = {isa =
PBXBuildFile; fileRef = 02F5CC870D149658A2D0 /* poptparse.c */; };
02F5CC910D149658A2D0 /* system.h in Headers */ = {isa =
PBXBuildFile; fileRef = 02F5CC880D149658A2D0 /* system.h */; };
02F5CCC00D1498A3A2D0 /* Popt.framework in Frameworks */ =
{isa = PBXBuildFile; fileRef = 02F5CC6D0D1494AAA2D0 /* Popt.framework */; };
+ 2234C2A00E2BE18200E7704C /* positiondef.h in Copy frameworks */
= {isa = PBXBuildFile; fileRef = 2234C29F0E2BE18200E7704C /* positiondef.h */;
};
9742E5730DF9975E000A5D41 /* lexer_input.c in Sources */ = {isa
= PBXBuildFile; fileRef = 9742E5710DF9975E000A5D41 /* lexer_input.c */; };
9742E5740DF9975E000A5D41 /* lexer_input.h in Copy frameworks */
= {isa = PBXBuildFile; fileRef = 9742E5720DF9975E000A5D41 /* lexer_input.h */;
};
9742E5770DF9979C000A5D41 /* parsetest.c in Sources */ = {isa =
PBXBuildFile; fileRef = 9742E5750DF9979C000A5D41 /* parsetest.c */; };
@@ -850,6 +851,7 @@
02DE76070DC3B84900D48F58 /* GLee.h in Copy
frameworks */,
9742E5740DF9975E000A5D41 /* lexer_input.h in
Copy frameworks */,
9742E5780DF9979C000A5D41 /* parsetest.h in Copy
frameworks */,
+ 2234C2A00E2BE18200E7704C /* positiondef.h in
Copy frameworks */,
);
name = Copy frameworks;
runOnlyForDeploymentPostprocessing = 0;
@@ -1048,7 +1050,6 @@
0246A0B90BD3CBD5004D1C70 /* strresly.h */ = {isa =
PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.c.h; name =
strresly.h; path = ../lib/framework/strresly.h; sourceTree = SOURCE_ROOT; };
0246A0BA0BD3CBD5004D1C70 /* treap.c */ = {isa =
PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.c.c; name =
treap.c; path = ../lib/framework/treap.c; sourceTree = SOURCE_ROOT; };
0246A0BB0BD3CBD5004D1C70 /* treap.h */ = {isa =
PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.c.h; name =
treap.h; path = ../lib/framework/treap.h; sourceTree = SOURCE_ROOT; };
- 0246A0BC0BD3CBD5004D1C70 /* treapint.h */ = {isa =
PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.c.h; name =
treapint.h; path = ../lib/framework/treapint.h; sourceTree = SOURCE_ROOT; };
0246A0BD0BD3CBD5004D1C70 /* trig.c */ = {isa =
PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.c.c; name =
trig.c; path = ../lib/framework/trig.c; sourceTree = SOURCE_ROOT; };
0246A0BE0BD3CBD5004D1C70 /* trig.h */ = {isa =
PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.c.h; name =
trig.h; path = ../lib/framework/trig.h; sourceTree = SOURCE_ROOT; };
0246A0BF0BD3CBD5004D1C70 /* types.h */ = {isa =
PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.c.h; name =
types.h; path = ../lib/framework/types.h; sourceTree = SOURCE_ROOT; };
@@ -1688,6 +1689,7 @@
02F5CC860D149658A2D0 /* poptint.h */ = {isa =
PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.c.h; name =
poptint.h; path = external/popt/poptint.h; sourceTree = SOURCE_ROOT; };
02F5CC870D149658A2D0 /* poptparse.c */ = {isa =
PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.c.c; name =
poptparse.c; path = external/popt/poptparse.c; sourceTree = SOURCE_ROOT; };
02F5CC880D149658A2D0 /* system.h */ = {isa =
PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.c.h; name =
system.h; path = external/popt/system.h; sourceTree = SOURCE_ROOT; };
+
Re: [Warzone-dev] 2.1 beta4
I'm interested in doing some OS X maintenance but have the same problem with time. Still, I can help out a few hours a week to hopefully cut down on the number of OS X bugs. I've been doing a little OS X bug work and have a slight familiarity with the codebase so feel free to direct things my way (or I can continue to look through the posted OS X bugs). Tim Ari Johnson wrote: On Sun, Jul 6, 2008 at 2:33 PM, Dennis Schridde [EMAIL PROTECTED] wrote: Am Sonntag, 6. Juli 2008 20:34:47 schrieb Dennis Schridde: Hey! I would like to release 2.1 beta4 as soon as possible. PS: This includes not waiting for any MacOS bugs. Since it appears to me we do not have a maintainer for that anymore, there is no sense in waiting for the bugs to be fixed by some magic. Ari: If I am wrong with that maintainer assumption, please notify me. You're right. I'm very busy and want to pass on the OS X maintenance to someone else, if anyone is interested. The OS X bugs are probably very easy to fix since they have all been introduced as we've gone along adding new features and changing around the code - the game worked nearly perfectly in 2.0.x. I just don't have time to hunt down all the regressions and fix them at this time. I definitely want to see the game remain workable on OS X, though, so hopefully someone else can step in. I'd be more than happy to help whoever does so get familiar with the code. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
