On Thu, Jul 13, 2023 at 04:34:39PM -0600, Karl Berry wrote: > Bogdan, Pat, Gavin, all - back on this bug: > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54063 > Subject: bug#54063: - special case] Try .texi.in when .texi missing >
> As previously discussed in this bug, I added a warning to automake.texi > about @setfilename having to match the basename if it's present. I think > a check+warning for that could usefully be added to the code in this > function (scan_texinfo_file), but I just can't cope with spending more > time on this issue. I also don't want to think about adding "full" > support for @setfilename to Automake, given that @setfilename is no > longer required or especially recommended for Texinfo. > > Wow, this is all confusing. I sure hope it works out (closing the bug, > probably prematurely). --thanks, karl. I didn't follow the details of the discussion closely, but it appears to relate to a theoretical problem that didn't actually affect anybody, only relevant if @setfilename was used. I agree that it appears to be an issue not worth spending much time on, and that adding full support for @setfilename to Automake would be a waste of time and effort. Looking at the thread of the original bug report above, the original problem appears to have been fixed by Mike Frysinger's change: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54063#17 Date: Thu, 24 Feb 2022 22:32:24 -0500 > Fixes automake bug https://bugs.gnu.org/54063. > > The function scanning for @setfilename will fall back to a default > value if the input doesn't have one defined. But we need to handle > the case where the file doesn't even exist before falling back. Thus, closing the bug makes sense. We can see if we can remove the workaround for the original problem in Texinfo if/when a new version of Automake is released.
