helpAutoconf - Support: sr #110364, obsolete agony


sr #110364: obsolete agony

Submitter:  Karl Berry <karl>
Submitted:  Thu 05 Nov 2020 05:31:47 PM UTC
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  Wont Do
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Operating System:  None
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


Thu 05 Nov 2020 11:41:14 PM UTC, comment #3: 

Well, of course it's not up to me, but I have to argue further. Sorry. It just feels like inflicting a lot of pain on maintainers for the sake of abstract cleanliness. Precisely because these macros have worked fine for so many years, it seems gratuitous to tell everyone to change them now without a serious benefit in return. Which I don't see from your description. Sure, the macros may be suboptimal, but they work. So why tell people to spend precious time changing them?

Especially "names were considered inconsistent" and "replaced with a more general or featureful mechanism". Who cares :)? Why does that make usage of the old macro worth my time to change? Answer: it doesn't. As far as I can see, those should never have been "declared" obsolete in the first place. It just feels like arbitrary change for change's sake. Ugh. Something I'd expect from Python, not Autoconf :).

As for the other macros, where obscurities are actually being fixed, if maintainers want to clean up their sources, great, they can enable the warnings. But in so many cases it's N steps upstream and/or not actively maintained anywhere, so the warnings will just be aggravation.

BTW, as for Automake (and other projects that have required gratuitous changes), I felt the same way there, but the changes were at least rather minor (though I felt equally irritated making them). Hacking all these Autoconf macros, and possible required code changes (no idea if the defined symbols change if the macros change), does not feel minor at all.

Grepping TeX Live for the obsolete macros, I see over 250 occurrences. Yikes! Most of them are in upstream libraries -- cairo, freetype, gd, gmp, harfbuzz, libpng, mpfr, pixman, teckit, zlib, zziplib, icu, lua, and various ax_* macros (from autoconf-archive, which is probably going to be affected terribly?), and upstream programs (won't bother to list). I think this change is going to be waking up a lot of maintainers, and not in any way that they would welcome.

Paul: I'm certainly not one to turn down help (thanks!), but I expect it might take you about the same amount of (or less, hopefully) time to go through the list of obsolete macros and document what needs to be done in each case. I think that would be a far better use of your time, helping everyone who runs into this.

But, in any case, if you want to see the TL source tree, you can get it with svn co svn://

Thanks for listening. Compatibility is one of my triggers, I guess.

Karl Berry <karl>
Project Member
Thu 05 Nov 2020 07:19:10 PM UTC, comment #2: 

I lean towards agreeing with Zack, in that the warnings are typically more helpful than harmful and should be on by default.

If it helps, I can volunteer to patch texlive to pacify the new Autoconf. The patches should all be simple.

Paul Eggert <eggert>
Project Administrator
Thu 05 Nov 2020 06:39:47 PM UTC, comment #1: 

First, thank you for trying a build of TeX Live with the new autoconf.  I'm pleased to hear that this was the only problem you encountered.

I could turn off -Wobsolete warnings by default, but I'm very reluctant to do so.  Most of these macros have been obsolete for a very long time (AC_TRY_*, for instance, were obsoleted in 2.55, eighteen years ago) -- the rationale is one or more of:

  • the names were considered inconsistent back in the early 2000s (AC_ERROR, AC_FOREACH, AC_FUNC_VFORK, possibly others)
  • the way the macro handles M4 quotation is bad (AC_TRY_*)
  • replaced with a more general or featureful mechanism (AC_PROG_CC_C99, AC_LANG_*, AC_HELP_STRING)
  • the portability problem this macro addresses is only relevant if you care about pre-C89 compilers and/or C libraries, and autoconf itself no longer supports those environments; you probably don't need to use them at all (AC_HEADER_STDC, AC_HEADER_STDC, AC_TYPE_SIGNAL)
  • it's not actually obsolete, but you need to give it an argument now to affirm that you do not depend on a bug in 2.69 (AC_PROG_LEX)

With the exception of the "names considered inconsistent" category, I would say that use of these macros really is a bug in the configure script, and the fact that they're still being used in TeX Live and many other packages is in fact why we want to turn these warnings on by default (or, more precisely, follow automake's decision to do so, for similar reasons).

In most cases the fix is very easy (e.g. change AC_FUNC_VFORK to AC_FUNC_FORK) and the fixed script will still work fine with 2.69.  It's true that neither the documentation nor the warning messages do a great job of explaining what to do in many cases, and that "just run autoupdate" works rather less well than I'd like.  I have my hands full with code issues and won't be able to improve the documentation myself, but I'd definitely consider patches (start with the "Obsolete Macros" section of autoconf.texi).

Zack Weinberg <zackw>
Project Administrator
Thu 05 Nov 2020 05:31:47 PM UTC, original submission:  

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 (, a fairly large tree with lots of packages, each with their own 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'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:

Karl Berry <karl>
Project Member


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by eggert (Posted a comment)
  • -email is unavailable- added by zackw (Posted a comment)
  • -email is unavailable- added by karl (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.





    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-11-15 zackw StatusNone Wont Do
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.9