bison-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: My plans for Bison


From: H. S. Teoh
Subject: Re: My plans for Bison
Date: Tue, 12 Feb 2019 10:55:56 -0800
User-agent: Mutt/1.10.1 (2018-07-13)

On Tue, Feb 12, 2019 at 12:34:49PM -0500, Eric S. Raymond wrote:
[...]
> 3.  I don't know if I can budget the time for this, it is several days
> solid work at minimum, but...the autoconf build recipe in Bison is
> (like all large old autoconf recipes) deeply horrible; it should be
> razed to the ground and replaced.
> 
> It used to be that teetering piles of kludges like this one were
> justified by their capability-discovery phase.  There wasn't
> realistically any other way to deal with Unix-variant issues and
> compiler vagaries.  But the value of that benefit has pretty much
> vanished since the mid-2000s due to pervasive compiler and OS
> standardization.  We no longer have deal with (for example) some
> systems having "string.h" and others having "strings.h"
> 
> Three years ago I removed a worse autoconf monstrosity than Yacc's
> from the NTP code base.  A couple days ago I de-autoconfiscated
> giflib. Many KLOC of m4 and shell cruft collapsed to two small
> makefiles with no conditionals.

I don't speak for the Bison maintainers, but I applaud this direction.
Large piles of legacy autoconf m4 just makes the code harder to maintain
for no substantial benefit. Basically you just end up wasting time
maintaining code that's no longer useful.  Being able to build Bison
with just a couple of makefiles with no conditionals is a very
attractive proposition to me -- though I expect that autoconf will
probably still be needed on some level to detect any dependent libraries
that may be required.


[...]
> If you're willing to assume that your target platforms are compliant
> with C99 and POSIX-1.2001 this is actually very low-risk.  I started
> making that assumption in 2009 on GPSD - ripped out autoconf and all
> the ancient #ifdefs - and haven't had even a microhassle about it in
> the eight years since.  And Bison is a much easier case; as a pure
> text processor its system dependencies are lighter.
[...]

Yes, in this day and age of standardization, we can assume a lot more
than we could back in the day.  Now that those old days are firmly in
the past, it's a good time to shed the accumulated baggage. I think C99
and POSIX-1.2001 is a pretty safe, conservative baseline to build on,
being almost 2 decades old by now.


T

-- 
Amateurs built the Ark; professionals built the Titanic.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]