mainAutoconf - Support: sr #110324, autoupdate does some nonsensical...


sr #110324: autoupdate does some nonsensical changes

Submitter:  Bruno Haible <haible>
Submitted:  Sun 04 Oct 2020 10:34:05 PM UTC
Votes: 2
Category:  None Priority:  1 - Later
Severity:  3 - Normal Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Operating System:  None
* Mandatory Fields

Add a New Comment Rich Markup

Mon 13 Jun 2022 03:26:15 PM UTC, comment #5: 

Yes, minimized reproduction recipes for erroneous changes would be really helpful.

I can't promise autoupdate will ever get fixed, both because of a general lack of developer time, and because I'm not convinced it's possible to fix some of these bugs short of a ground-up redesign built around an actual parser for both M4 and shell constructs.  (See the long comment starting at for a bunch of backstory -- what we have now is the fifth attempt to design an auto-updater, and it's still got these problems!)  But right now all we have is anecdotes coupled to long diffs like the ones you and Bruno posted.  Minimized reproduction recipes would let us think concretely about how the existing algorithm goes wrong and figure out what, if anything, can be done about it.

Zack Weinberg <zackw>
Group administrator
Sun 12 Jun 2022 11:52:21 PM UTC, comment #4: 

comment #3:

> Since autoupdate uses a "brittle" algorithm, as Zack wrote, I think what you report will be hard or impossible to reproduce if you don't attach the input file(s).

Hi, the input files can be found in my "autotools-tinkering" branch of gcc:
In particular commit 6b44b2c contains a lot of the screw-ups:
I can try reducing some reproducers from it if you'd like; should I?

Eric Gallager <egallager>
Sun 12 Jun 2022 06:20:15 PM UTC, comment #3: 

Since autoupdate uses a "brittle" algorithm, as Zack wrote, I think what you report will be hard or impossible to reproduce if you don't attach the input file(s).

Bruno Haible <haible>
Sun 12 Jun 2022 05:34:20 PM UTC, comment #2: 

I've noticed a bunch of these, too:

1) Nested AC_TRY_COMPILE/AC_TRY_LINK/AC_TRY_RUN invocations lead to stray _au_m4_changequote([,])s when being autoupdated to AC_COMPILE_IF_ELSE/AC_LINK_IF_ELSE/AC_RUN_IF_ELSE
2) Macros in comments get expanded even when the new output spreads across more lines, meaning that stuff that ought to stay in a comment no longer is
3) Stuff inside AC_REQUIRE gets autoupdated even when that breaks the usage of AC_REQUIRE (similar to the previous)
4) If someone had been writing their to abide by certain style rules (e.g. 80-character line limits), autoupdate will ignore those and reformat things

I've been noticing a bunch of these while autoupdating various stuff over the years but am only getting around to writing them down as of my beginning of work on autoupdating the GCC configury as per this bug:

Should I open separate bugs for each additional item that I notice, or just continue to catalogue them here?

Eric Gallager <egallager>
Fri 30 Oct 2020 08:47:57 PM UTC, comment #1: 

Regrettably, I do not think it will be possible to make any improvements to autoupdate for 2.70.  The algorithm it uses is already extremely brittle and I'm buried in regressions in automake itself.

Zack Weinberg <zackw>
Group administrator
Sun 04 Oct 2020 10:34:05 PM UTC, original submission:  

In Zack Weinberg wrote:
"The diff produced by autoupdate is mostly not usable as is.   In fact, it looks to me more like a todo list for bugs and missing features in autoupdate itself :-/"

Here is another example, from GNU gperf. Find the input and the changes by autoupdate 2.69c attached.

1) Changing AC_PREREQ([2.64]) to AC_PREREQ([2.69c]) — or, once 2.70 is released, to AC_PREREQ([2.70]) — is unwelcome, because many distros which run autoreconf will not have autoconf 2.70 is installed.
While it is certainly OK to change AC_PREREQ([2.13]) to AC_PREREQ([2.64]) or so, AC_PREREQ([2.69c]) is a too strong requirement.

2) Changing AC_LANG_SAVE() to m4_warn(...) is nonsense.

3) Leaving AC_LANG_SAVE in the output is not good, because autoupdate is meant to eliminate this call.

The other parts are helpful, though.

Bruno Haible <haible>


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

Attach Files:

Attached Files
file #49921: added by haible (1KiB - text/x-patch)
file #49920: added by haible (2KiB - application/octet-stream)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by egallager (Voted in favor of this item)
  • -email is unavailable- added by egallager (Posted a comment)
  • -email is unavailable- added by zackw (Posted a comment)
  • -email is unavailable- added by haible (Submitted the item)

    There are 2 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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-07-14 egallager Carbon-Copy- Added egallager
    2020-10-30 zackw Priority5 - Normal 1 - Later
    2020-10-04 haible Attached File- Added, #49921
    2020-10-04 haible Attached File- Added, #49920

    Back to the top

    Powered by Savane 3.12