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
