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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Is it time to drop fix-old-flex-code.pl?
Дата
Msg-id 1051721.1663770085@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: Is it time to drop fix-old-flex-code.pl?
Список pgsql-hackers
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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Mingw task for Cirrus CI
Следующее
От: Melih Mutlu
Дата:
Сообщение: Removing unused parameter in SnapBuildGetOrBuildSnapshot