[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[sr #110364] obsolete agony
From: |
Karl Berry |
Subject: |
[sr #110364] obsolete agony |
Date: |
Thu, 5 Nov 2020 12:31:49 -0500 (EST) |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 |
URL:
<https://savannah.gnu.org/support/?110364>
Summary: obsolete agony
Project: Autoconf
Submitted by: karl
Submitted on: Thu 05 Nov 2020 09:31:47 AM PST
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
Status: None
Privacy: Public
Assigned to: None
Originator Email:
Open/Closed: Open
Discussion Lock: Any
Operating System: None
_______________________________________________________
Details:
Zack and all - is it really necessary to warn about "obsolete" macros now? Why
are they obsolete, anyway? Presumably they still work. So what's the advantage
of telling maintainers to spend precious time updating them to something else
(not obvious what)? Can't we just declare them "good forever"? People do not
idly discard, or want to update, working software without some significant
benefit in return. Especially in areas as touchy as autotools.
I just ran autoconf-2.69d on TeX Live (tug.org/texlive), a fairly large tree
with lots of packages, each with their own configure.ac. So running autoupdate
is not trivial and not likely to help, either, since the claimed-obsolete
macros are mostly in common included .m4 files, not individual
configure.ac's.
The list of macros warned about are below. It seems most of these have been
around since the very early days, and are quite fundamental. I suspect many
packages use them. It would be exceedingly painful to have to look up how I'm
"supposed" to do it now for all cases (the warning messages give no clue). All
for ... what reason? I don't get it.
I guess I can (and would) add -Wno-obsolete, but ... I suspect nearly everyone
with nontrivial projects is going to have similar problems. So how about
keeping the status quo, leaving obsolete warnings off by default? Let those
who want to worry about such things (a near-null set, I would bet) turn it
on.
Apart from all that, I was very happy to see that all the generated configure
scripts and Makefiles still worked fine (at least my initial build of the
whole TL tree succeeded), which is the most important thing. That is an
impressive achievement. So thanks for retaining compatibility there. --karl
Here is the macro list:
AC_ERROR
AC_FOREACH
AC_FUNC_VFORK
AC_HEADER_STDC
AC_HEADER_TIME
AC_HELP_STRING
AC_LANG_C
AC_LANG_CPLUSPLUS
AC_PROG_CC_C99
AC_PROG_LEX
AC_TRY_COMPILE
AC_TRY_LINK
AC_TRY_RUN
AC_TYPE_SIGNAL
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/support/?110364>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
- [sr #110364] obsolete agony,
Karl Berry <=