Add a New Comment (Rich Markup)
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 https://git.savannah.gnu.org/cgit/autoconf.git/tree/bin/autoupdate.in#n420 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.
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: https://github.com/gcc-mirror/gcc/compare/master...cooljeanius:me/autotools-tinkering In particular commit 6b44b2c contains a lot of the screw-ups: https://github.com/gcc-mirror/gcc/commit/6b44b2c391c1132acc8cfdefe83e2e614b8e590d I can try reducing some reproducers from it if you'd like; should I?
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).
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 configure.ac 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103459 Should I open separate bugs for each additional item that I notice, or just continue to catalogue them here?
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.
In https://lists.gnu.org/archive/html/bug-gnulib/2020-09/msg00158.html 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.
(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)
Attach Files: Comment:
Depends on the following items: None found
Items that depend on this one: None found
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.
Please enter the title of George Orwell's famous dystopian book (it's a date):
Follow 3 latest changes.
Copyright © 2023 Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team. Source Code
Powered by Savane 3.12