[Olsr-users] compile error in olsrd-0.5.6-r3

[L. Aaron Kaplan]

On Jan 31, 2009, at 12:44 AM, Patrick McCarty wrote:

> I hadn't played with the new patch. And I agree I also would not
> consider it a bug. I simply was relating my personal experience
> wherein Bison was the cause of my compile troubles, specifically on
> BSD. So, I have no technical point other than using other versions of
> bison fixed the problem.
>
> To be clear, I didn't blame OLSR for any of that, and I apologize if
> you felt that was bashing.

*My* personal interpretation of Bernds mail:
Dont worry, that was simply Bernds writing style for getting thru a  
most detailed point he felt he *had* to raise.  Sounds like more of an  
internal scolding of fellow coders.
;-)

Anyway, to stay on topic: the bison code is gone in the development  
tip thanks to Sven-Ola who replaced it by a hand written parser. You  
can test that and see if you have any build errors. I just compiled  
tip on OS X and there are warnings or errors (but there are some on  
OpenBSD still).

a.

>
>
> Patrick
>
> On Fri, Jan 30, 2009 at 5:28 AM, Bernd Petrovitsch <(spam-protected)>  
> wrote:
>> On Thu, 2009-01-29 at 19:46 -0500, Patrick McCarty wrote:
>>> That's good news. Bison was the cause of some breakage on some
>>
>> Not really. I read one mail of a reviewer - the only one I saw - of  
>> the
>> replacement code and judging from that it's probably much safer to  
>> just
>> revert that "patch".
>>
>>> particular BSD builds. This should help make things more compatible.
>>
>> That is also plain simply wrong - that breakage is not even a "bug"  
>> in
>> the widest sense as it may happen on handwritten code too. It's just
>> that newer gcc's tend to have better optimizers and checking so that
>> issues in "old code" are raised.
>>
>> Can we please stop technically unfounded bison, flex and other code
>> generator tool bashing (for whatever reason) without any substantial
>> technical points.
>>
>> For the protocol:
>> - the warnings there (and the perl/sed/... snippets to cure those)  
>> were
>> introduced by me to get an idea if and how good the generated code  
>> is.
>> Given the age of these tools (and their predecessors yacc and lex)  
>> and
>> portability requirements for the generated code, it is far better  
>> (and
>> more readable!) than lots of handwritten code I saw in my life.
>> - at that time, release didn't had an -Werror (and several warnings)
>> activated because otherwise the handwritten code also had lots of
>> warnings (more than the generated ones).
>> - -Werror was activated in the development to force people to think.
>> But it was disabled for releases - just because it would break on  
>> some
>> too old or too new gcc version somewhere.
>> - at some point in time all warnings != -Werror were activated  
>> because
>> the code triggering the warnings were fixed.
>> - someone (I don't know who and/or when later on) activated -Werror  
>> also
>> for releases.
>>
>> So it's IMHO just a question of time that old release (with -Werror)
>> plain simply won't build on too new gcc's (and that may happen on
>> handwritten code too).
>>
>> So please can I have any technical, valid and sane reason, which  
>> class
>> of problems is solved by replacing the use of old and proven code
>> generators with handwritten code?
>> I can't see or even think of any.
>>
>> [ Fullquote deleted. Can we stop <pleonasm>unreadable full
>> quoting</pleonasm> too. Thank you.]
>>
>>       Bernd, fed up with repeatedly technically unfounded bashing
>> --
>> Firmix Software GmbH                   http://www.firmix.at/
>> mobil: +43 664 4416156                 fax: +43 1 7890849-55
>>         Embedded Linux Development and Services
>>
>>
>>
>> --
>> Olsr-users mailing list
>> (spam-protected)
>> http://lists.olsr.org/mailman/listinfo/olsr-users
>>
>
> -- 
> Olsr-users mailing list
> (spam-protected)
> http://lists.olsr.org/mailman/listinfo/olsr-users