Re: My plans for Bison: simplify autotools use

[Akim Demaille]

Hi all,

> Le 12 févr. 2019 à 19:55, H. S. Teoh <address@hidden> a écrit :
> 
> 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.

I would love to agree, but I don't.

First of all, what exactly are we referring to?  configure.ac is
extremely small: it's less than 300 lines.

Eric, you refer to ancient ifdef you removed elsewhere.  Well, there's
not much to do in the case of Bison.

$ git grep -l HAVE_
ChangeLog-1998
ChangeLog-2012
doc/Doxyfile.in

So, for a start, there is not one HAVE_ in Bison's code.

Then #if maybe?  If I get rid of NEWS, ChangeLog, the code in the generated
parsers, the CPP guards for multiple inclusion of headers, I get:

$ git grep '# *if' | grep -Ev 
'NEWS|ChangeLog|INCLUDED|skeleton|parse-gram|tests/|(_H_?$)|etc|doc'
TODO:#if YYLSP_NEEDED
bootstrap:# if we were invoked as "sh bootstrap".
build-aux/cross-options.pl:            # if $opt, $arg contains the closing ].
examples/c++/variant.yy:#if !defined __cplusplus || __cplusplus < 201103L
lib/path-join.h:# ifdef __cplusplus
lib/path-join.h:# ifdef __cplusplus
m4/flex.m4:#ifdef YYTEXT_POINTER
src/flex-scanner.h:#ifndef FLEX_PREFIX
src/flex-scanner.h:#if defined __GNUC__ && ! defined __clang__ && 6 <= __GNUC__
src/flex-scanner.h:#if FLEX_VERSION <= 20060000 && defined __clang__
src/flex-scanner.h:#if FLEX_VERSION <= 2005031
src/flex-scanner.h:#ifndef yyleng
src/flex-scanner.h:#ifndef yytext
src/flex-scanner.h:#if FLEX_VERSION <= 2005009
src/flex-scanner.h:#ifndef FLEX_NO_OBSTACK
src/getargs.c:#if (defined __GLIBC__ && __GLIBC__ >= 2) && !defined __UCLIBC__
src/getargs.c:#ifdef MSDOS
src/scan-gram.l:#if ! ('$' == 0x24 && '@' == 0x40 && '`' == 0x60 && '~' == 0x7e)
src/system.h:# if ! defined __STDC_VERSION__ || __STDC_VERSION__ < 199901
src/system.h:# ifndef UINTPTR_MAX
src/system.h:# ifndef __attribute__
src/system.h:#  if (! defined __GNUC__ || __GNUC__ < 2 \
src/system.h:# if __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 7)
src/system.h:# ifndef ATTRIBUTE_NORETURN
src/system.h:# ifndef ATTRIBUTE_UNUSED
src/system.h:# ifndef OUTPUT_EXT
src/system.h:# ifndef TAB_EXT
src/system.h:# if WITH_DMALLOC
src/tables.c:#if 0 /* Not currently used.  */

I don't think that this is much.


Yes, there are some hairy Autoconf macros.  For instance I try several
C++ standards, and see what options are needed to pass to the compiler
to enable them (and make sure it supports some of the features we need).
But I don't see how to not do that.


So, AFAICT, Bison in itself is quite clean.


However, the lib C is quite small and offers little features.  We need
bitsets, we need lists, we need plenty of things that are offered by
gnulib.  And gnulib aims at maximum portability.  I do not plan to
get independent of gnulib, so today, Bison is probably way more portable
than actually needed, but that effort is not on our shoulders, and
anyway, again, we need plenty of components that just don't exists
elsewhere.

> Being able to build Bison
> with just a couple of makefiles with no conditionals is a very
> attractive proposition to me 

Well, to me too.  But that cannot be done.  Unless you are proposing to
commit yourself to maintain all the extra C libraries we need in Bison.
And I really mean "commit yourself".  There are not enough maintainers
for Bison, and I do what I can with the time I can offer here.  And
maintaining this library is way out of my reach.

> Basically you just end up wasting time
> maintaining code that's no longer useful.  

No, I exactly do not.  I maintain nothing at all.  I enjoy the ride on
the back of gnulib.

That's exactly the point: I don't maintain anything in the base layers
Bison is implemented on.  Will you?