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 [email protected] https://mail.gna.org/listinfo/warzone-dev
