[PATCH libxkbcommon 0/2] Use flex and bison features

Gaetan Nadon memsize at videotron.ca
Sat Feb 25 05:42:53 PST 2012


On 12-02-25 04:09 AM, Ran Benita wrote:
> On Fri, Feb 24, 2012 at 06:56:28PM -0500, Gaetan Nadon wrote:
>> On 12-02-24 02:25 PM, Ran Benita wrote:
>>> On Fri, Feb 24, 2012 at 10:16:39AM -0500, Gaetan Nadon wrote:
>>>> On 12-02-23 07:58 PM, Ran Benita wrote:
>>>>> - I couldn't figure out the coding style (there seems to be use of
>>>>>   *all* of them...), so I just tried to match the surroundings.
>>>>> - I've been using libxkbcommon for some time and I have some more
>>>>>   patches laying around. I can send them too if all is well.
>>>>>
>>>> These look perfect to me. I build them on Linux with bison 2.4.1 and
>>>> flex 2.5.35.
>>>> I don't know if there could be differences on other platforms such as
>>>> Solaris, *BSD MAC, it does not look like there would be any bison/flex
>>>> specific features being used.
>>>>
>>>> The title of the e-mail makes it sound like you are using features that
>>>> are specific to flex & bison as opposed to lex & yacc. You are also
>>>> saying you are breaking compatibility with lex & yacc, I am confused. I
>>>> suppose you are aware that this library builds on multiple platforms
>>>> with a variety of scanner/lexer. We document the tools requirements in
>>>> http://www.x.org/wiki/ModularDevelopersGuide#Required_Tools, but it is
>>>> not very clear in this case.
>>> Thanks for the link. I wasn't previously aware of byacc; I tried it now.
>>> The first patch works fine, but the second does rely on a bison-only
>>> feature (the YYLTYPE location stuff). But does the link mean that I
>>> should refactor the code to work with byacc as well (probably possible
>>> with some #ifdef's)? I would imagine that if flex is required for a
>>> given platform (as per the link), than bison should be available as
>>> well. I can also add some configure checks if necessary.
>> I have updated the wiki to reflect what I perceived to be the reality at
>> the moment based on the discussion in this thread.
>>
>>     *yacc*   The original AT&T parser generator or an upward compatible
>>     version such as *bison* or *byacc* whitout using its specific features
>>
>>     *lex*   The original AT&T lexical analyser generator or an upward
>>     compatible version such as *flex* whitout using its specific features
> OK, I guess these patches are dropped than; I'll rebase my other
> patches. I must say that AT&T lex and yacc is rather limiting this day
> and age, for a library at least. It means that the parser cannot be made
> to work reliably in a threaded application and other scenarios.
>
Can you not retain the patch that replaces tokens.h with the generated one?
All other packages using lex & yacc use the -d option, so it is not
bison specific I suppose.

Given you are familiar with this library, would you be so kind as to
write an opening paragraph in the README file to describe what this
library is for? We do this for almost all modules.
http://lists.x.org/archives/xorg-devel/2009-April/000753.html

Thanks



More information about the xorg-devel mailing list