Thread: Is it time to drop fix-old-flex-code.pl?

In view of

Author: John Naylor <john.naylor@postgresql.org>
Branch: master [8b878bffa] 2022-09-09 12:55:23 +0700

    Bump minimum version of Flex to 2.5.35

I wonder if we should go a little further and get rid of
src/tools/fix-old-flex-code.pl (just in HEAD, to be clear).
That does nothing when flex is 2.5.36 or newer, and even with
older versions it's just suppressing an "unused variable" warning.
I think there's a reasonable case for not caring about that,
or at least valuing it lower than saving one build step.

According to a recent survey, these are the active buildfarm
members still using 2.5.35:

 frogfish      | 2022-08-21 17:59:26 | configure: using flex 2.5.35
 hoverfly      | 2022-09-02 16:02:01 | configure: using flex 2.5.35
 lapwing       | 2022-09-02 16:40:12 | configure: using flex 2.5.35
 skate         | 2022-09-02 07:27:10 | configure: using flex 2.5.35
 snapper       | 2022-09-02 13:38:22 | configure: using flex 2.5.35

lapwing uses -Werror, so it will be unhappy, but I don't think it's
unreasonable to say that you should be using fairly modern tools
if you want to use -Werror.

Or we could leave well enough alone.  But the current cycle of
getting rid of ancient portability hacks seems like a good climate
for this to happen.  Thoughts?

            regards, tom lane

On Wed, Sep 21, 2022 at 10:21:25AM -0400, Tom Lane wrote:
>
> lapwing uses -Werror, so it will be unhappy, but I don't think it's
> unreasonable to say that you should be using fairly modern tools
> if you want to use -Werror.

I think that the -Werror helped to find problems multiple times (although less
often than the ones due to the 32bits arch).  If it's worth keeping I could see
if I can get a 2.5.36 flex to compile, if we drop fix-old-flex-code.pl.