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

Reply via email to