Re: Build issues due to patch "gprofng: a new GNU profiler" – CLOCK_MONOTONIC_RAW not defined

[Nick Alcock <nick.alcock@oracle.com>]

On 14 Mar 2022, Joseph Myers outgrape:
> (I might ask incidentally why the Bison output files QLParser.tab.cc and 
> QLParser.tab.hh are checked in - normally binutils doesn't commit Bison 
> output files to the repository on master, although it makes sure to 
> include them in release tarballs.  If there's a Bison version dependency 
> issue, then arrange not to build gprofng when the installed Bison is too 
> old.)

There is. Since we have a reentrant parser, we need either gross
hand-hacking of the generated parser to move everything into a class
(which is what the code *used* to do, and is a non-starter in my eyes),
or at least Bison 3.3 (for api.parser.class): it is quite possible that
some dependency on a later Bison has crept in, but that's not
*fundamental* to the parser the way the api.parser.class dependency is.

The right approach seems to me to be to check the generated parser into
the disted release tarball, and then to configure gprofng only if Bison
is sufficiently recent or if the generated parser is already present
(i.e. this is a release tarball). In any case the generated parser would
disappear from version control and dbe/Makefile.am would gain rules to
regenerate it (and also at dist time for the tarball).

I think the default Automake rules already do this, as do the gnulib
rules we would probably have to use instead due to the Automake rules
forcing bison -y. At any rate this does not look impossible, or even
that hard, certainly not compared to rewriting the parser or something.
And there's certainly no justification for bumping the treewide bison
version (if there even is one: I thought there was, but now I look for
it I can't find it). The only people who will need to upgrade bison for
this are people building gprofng from git checkouts and who want its
building to not be skipped, who are presumably either developing gprofng
(in which case upgrading bison is no trouble), or are distributors
working in recent distro leading edges (in which case they are almost
certainly both used to upgrading bison and are using a newer version
already).


It looks like the skip-configure-if-unsuitable stuff is hardwired into
the top-level configure.ac, but it also looks like it can use basically
any reason to suppress building of single directories, so checking for
new-bison-or-gprofng/dbe/QLParser.cc-exists seems at least technically
doable.

Does this all seem sane to everyone else?

-- 
NULL && (void)