[sr #110324] autoupdate does some nonsensical changes

[Eric Gallager]

Follow-up Comment #7, sr#110324 (group autoconf):

[comment #6 comment #6:]
> Still waiting for those minimized reproduction recipes for erroneous
changes, and probably also for a volunteer who really wants to take a deep
dive on autoupdate.

I've been meaning to reduce a testcase for this, but haven't gotten any
further than setting up the directories for it; sorry... still on my TODO
list...



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110324] autoupdate does some nonsensical changes

[Zack Weinberg]

Update of sr#110324 (group autoconf):

  Status:None => Need Info  

___

Follow-up Comment #6:

Still waiting for those minimized reproduction recipes for erroneous changes,
and probably also for a volunteer who really wants to take a deep dive on
autoupdate.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110324] autoupdate does some nonsensical changes

[Zack Weinberg]

Follow-up Comment #5, sr #110324 (project autoconf):

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.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110324] autoupdate does some nonsensical changes

[Eric Gallager]

Follow-up Comment #4, sr #110324 (project autoconf):

[comment #3 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?



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110324] autoupdate does some nonsensical changes

[Bruno Haible]

Follow-up Comment #3, sr #110324 (project autoconf):

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).


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110324] autoupdate does some nonsensical changes

[Eric Gallager]

Follow-up Comment #2, sr #110324 (project autoconf):

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?



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110324] autoupdate does some nonsensical changes

[Zack Weinberg]

Update of sr #110324 (project autoconf):

Priority:  5 - Normal => 1 - Later  

___

Follow-up 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.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/