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 futu
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 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 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 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
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
Index: macosx/Warzone.xcodeproj/project.pbxproj
===
--- macosx/Warzone.xcodeproj/project.pbxproj(revision 5880)
+++ macosx/Warzone.xcodeproj/project.pbxproj(working copy)
@@ -681,7 +681,7 @@
"${DERIVED_FILES_DIR}/${INPUT_FILE_BASE}.tab.h",
"${DERIVED_FILES_DIR}/${INPUT_FILE_BASE}.tab.c",
);
- script = "external/bison/src/bison -y -d
-o\"${DERIVED_FILES_DIR}/${INPUT_FILE_BASE}\".tab.h \"${INPUT_FILE_PATH}\" ||
exit 1\nexternal/bison/src/bison -y -d
-o\"${DERIVED_FILES_DIR}/${INPUT_FILE_BASE}\".tab.c \"${INPUT_FILE_PATH}\" ||
exit 1";
+ script = "external/bison.sh -y -d
-o\"${DERIVED_FILES_DIR}/${INPUT_FILE_BASE}\".tab.h \"${INPUT_FILE_PATH}\" ||
exit 1\nexternal/bison.sh -y -d
-o\"${DERIVED_FILES_DIR}/${INPUT_FILE_BASE}\".tab.c \"${INPUT_FILE_PATH}\" ||
exit 1";
};
0246AA730BD3E47F004D1C70 /* PBXBuildRule */ = {
isa = PBXBuildRule;
@@ -3793,7 +3793,7 @@
);
runOnlyForDeploymentPostprocessing = 0;
shellPath = /bin/sh;
- shellScript =
"DIRECTORY=\"bison-2.3\"\nOUTDIR=\"bison\"\nEXECUTABLE=\"`pwd`/$OUTDIR/src/bison\"\nFILENAME=\"bison-2.3.tar.bz2\"\nSOURCE=\"http://ftp.gnu.org/gnu/bison/bison-2.3.tar.bz2\"\nMD5=\"c18640c6ec31a169d351e3117ecce3ec\"\n\n##
Fetch source ##\n\ncd external\n\nif [ -d \"$OUTDIR\" ]; then\n echo
\"$OUTDIR 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\nexit 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/^.*\\.\\([^.]*\\)/\\1/'`\n\nif [
\"$EXTENSION\" = \"gz\" ]; then\n if ! tar -zxf \"$FILENAME\"; then\necho
\"Unpacking $FILENAME failed\" >&2\nexit 1\n fi\nelif [ \"$EXTENSION\" =
\"bz2\" ]; then\n if ! tar -jxf \"$FILENAME\"; then\necho \"Unpacking
$FILENAME failed\" >&2
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
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 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. ___ 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
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=5877&view=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
