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
