bug-autoconf
[Top][All Lists]
Advanced

[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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]