Tim Baumgartner wrote:
> 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.
>
Alright, hopefully the m4sugar problem should be solved in the trunk as of
r5887. Bison is now properly installed to a directory ("built") in the Bison
source directory and the bison.sh script has been updated with the new binary
location.
Tim
_______________________________________________
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
