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

Reply via email to