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
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. :) ___ 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
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.' ___ 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
On Tue, Aug 26, 2008 at 10:27 AM, Ari Johnson [EMAIL PROTECTED] wrote:
Author: ari
Date: Tue Aug 26 17:27:40 2008
New Revision: 5877
URL: http://svn.gna.org/viewcvs/warzone?rev=5877view=rev
Log:
Committed patch from mailing list message [EMAIL PROTECTED]
due to Tim Baumgartner.
Modified:
trunk/macosx/Warzone.xcodeproj/project.pbxproj
Thanks Tim! The game doesn't quite build for me, but this is a huge
step. The build fails with:
/bin/sh -c external/bison/src/bison\ -y\ -d\
-o\${DERIVED_FILES_DIR}/${INPUT_FILE_BASE}\.tab.h\
\${INPUT_FILE_PATH}\\ ||\ exit\ 1
external/bison/src/bison\ -y\ -d\
-o\${DERIVED_FILES_DIR}/${INPUT_FILE_BASE}\.tab.c\
\${INPUT_FILE_PATH}\\ ||\ exit\ 1
/Users/ari/work/warzone/trunk/macosx/../lib/framework/resource_parser.y:
warning: conflicting outputs to file
`/Users/ari/work/warzone/trunk/macosx/build/Warzone.build/Debug/Warzone.build/DerivedSources/resource_parser.tab.h'
external/bison/src/bison: cannot open file
`/usr/local/share/bison/m4sugar/m4sugar.m4': No such file or directory
** BUILD FAILED **
It looks like the locally-built Bison should get a ./configure flag or
a patch to point it to its distribution files for m4sugar.m4 (and
possibly others).
___
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
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). Regards, Freddie. ___ 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] [Warzone-commits] r5877 - /trunk/macosx/Warzone.xcodeproj/project.pbxproj
On Tue, Aug 26, 2008 at 2:46 PM, Tim Baumgartner [EMAIL PROTECTED] 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). Should be easy enough. 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. Same here. I'm excited that things are coming together for the OS X port again. It's hard to keep up sometimes but it'll be worth it when I can play Warzone multiplayer on my G5 Mac, a friend's Intel Mac, and Windows and Linux machines online. The last multiplayer Warzone game I played was a day-long match on BasingStoke I believe, played on a LAN in 1999. 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. Awesome. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
