Re: My plans for Bison: simplify autotools use

[Eric S. Raymond]

Akim Demaille <address@hidden>:
> First of all, what exactly are we referring to?  configure.ac is
> extremely small: it's less than 300 lines.

300 less lines is 300 lines less.  And you left out the over 1KLOC of
bootstrap script - that has to be counted as a cost, too.

But the real tell that Bison's build recipe is overengineered is the
number of steps it requires.  It's time to ask "Why is it not just
"make"?  Or, if not make, some other single step?

I submit to you that the "bootstrap" and "configure" steps are useless
weight, or so close to it that we should be looking seriously at scrapping
the whole system and replacing it with a plain Makefile and maybe a few 
*small* auxiliary shellscripts. 

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

Which is a pretty powerful *argument* that the "bootstrap" and
"configure" steps are useless weight.

Step back a moment and remember when and why autoconf was originally
fielded in 1991.  I remember it; I was there, and an early adopter.
It was a reaction to the platform wars of the 1980s. Something was
needed that could examine the build environment for its features
(especially variant include headers) and set up all the right
compile-time conditionals.

That used to mean, in particular, a lot of HAVE_ symbols.

We don't live in that world anymore.  Standard C and POSIX have
bulldozed away most of those platform variations. Thus Bison has
gradually shed its HAVE_ symbols.  It has company; there was only one
HAVE_ symbol left in giflib when I de-autoconfiscated that two days
ago.

If the HAVE_ symbols are gone, what is left to justify what autoconf
is doing?  It is very helpful that you made that list of #ifs. Let's 
look through it together...

> 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'

Good filtering. 

> TODO:#if YYLSP_NEEDED
> bootstrap:# if we were invoked as "sh bootstrap".
> build-aux/cross-options.pl:            # if $opt, $arg contains the closing ].

We can ignore these for obvious reasons.

> examples/c++/variant.yy:#if !defined __cplusplus || __cplusplus < 201103L
> lib/path-join.h:# ifdef __cplusplus
> lib/path-join.h:# ifdef __cplusplus

GCC sets those, not a problem.

> m4/flex.m4:#ifdef YYTEXT_POINTER

This is a real issue; Bison needs to know a type that different lex-like
programs export differently.

> src/flex-scanner.h:#ifndef FLEX_PREFIX

Another real issue, another FLEX parameter.

> src/flex-scanner.h:#if defined __GNUC__ && ! defined __clang__ && 6 <= 
> __GNUC__

Compiler sets those

> src/flex-scanner.h:#if FLEX_VERSION <= 20060000 && defined __clang__
> src/flex-scanner.h:#if FLEX_VERSION <= 2005031

A FLEX parameter.

> src/flex-scanner.h:#ifndef yyleng
> src/flex-scanner.h:#ifndef yytext

Internal FLEX macros.

> src/flex-scanner.h:#if FLEX_VERSION <= 2005009

See above.

> src/flex-scanner.h:#ifndef FLEX_NO_OBSTACK

I remember this depends on an implementation feature of FLEX.  So we

> 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

The compiler can 

> src/system.h:# ifndef UINTPTR_MAX

We can assume that exists, it's defined in stdint.h.

> src/system.h:# ifndef __attribute__
> src/system.h:#  if (! defined __GNUC__ || __GNUC__ < 2 \
> src/system.h:# if __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 7)

Compiler sets those.

> src/system.h:# ifndef ATTRIBUTE_NORETURN
> src/system.h:# ifndef ATTRIBUTE_UNUSED

These are real compiler attributed, by they can be unset and the build will
work with both gcc and clang.

> src/system.h:# ifndef OUTPUT_EXT
> src/system.h:# ifndef TAB_EXT

Can be set to change output file extensions for Bison.

> src/system.h:# if WITH_DMALLOC

> src/tables.c:#if 0 /* Not currently used.  */

Handles itself
 
> I don't think that this is much.

I agree. For both Bison itself and gnulib it is sufficient to set these
knobs: 

YYTEXT_POINTER
FLEX_PREFIX
FLEX_VERSION
FLEX_NO_OBSTACK
ATTRIBUTE_NORETURN
ATTRIBUTE_UNUSED
OUTPUT_EXT
TAB_EXT

For this we have 1300 lines of shell and m4?  Pardon me, but this seems silly.
Especially since OUTPUT_EXT and TAB_EXT hardly ever need to be set at all.

I bet I could wite a Python script to handle all that *and* launch the
build in 150 lines absolute tops. Probaly less

> 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.

I think I see how.  Shall I try?

> So, AFAICT, Bison in itself is quite clean.

Agreed.
 
> 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.

I don't see any configration symbols for gnulib.

> 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?

I won't.  But...this sound like a case for moving Bison to Go. :-)
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.