Introducing an annoying, spurious warning on code recommended by the automake manual does seem important enough that it should be fixed in the very next release, but bad warning messages by themselves never rise to the level of a critical problem.  Are you saying that you're not getting your own version.m4 anymore when you do `m4_include([version.m4])` ?

Let me quote first feedback:
Nick Bowler wrote:> On 2024-01-13 03:26, Румен Петров wrote:

>> autoconf 2.72 is first release that prints warning:
>> configure.ac:2: warning: file 'version.m4' included several times
>
> The warning here is erroneous and happens now because Autoconf-2.72's
> m4sugar.m4 (which is used under the hood basically everywhere) now
> includes an expansion of m4_sinclude([version.m4]).
>
> Autoconf implements this warning with a very simplisic check for whether
> a file is actually included multiple times: it defines the m4_include
> and m4_sinclude macros which record the argument any time they are used,
> checking if either was ever called with that argument before.
>
> Now, m4sugar does not actually include your version.m4, because the
> Autoconf build/installation process generates an m4 "frozen state" file
> (m4sugar.m4f) where the file inclusion is already done using version.m4
> from Autoconf's source code, and this is what actually gets used when
> you run autoconf.  However, the frozen state does include the record
> that m4_sinclude was expanded previously with the version.m4 argument.
>
> Probably we could fix this problem by changing m4sugar.m4 to not use
> the m4_sinclude.  It could use m4_builtin([sinclude], [version.m4])
> instead which would then not expose the record of internal inclusions
> to the user like this.
>
> To work around the warning in autoconf-2.72, you can change the spelling
> of version.m4 to something functionally equivalent, for example:
>
>    m4_include([./version.m4])
>
> You can also just go in and delete the indication that Autoconf uses
> to produce this warning, for example:
>
>    m4_builtin([undefine], [m4_include(version.m4)])
>
> Incidentally, while not relevant to your example, Autoconf 2.72 also
> installs its own version.m4 file to the global m4 include search path,
> so if you were previously using M4PATH or autoconf's -I option to locate
> a file with this name then actually m4_include([version.m4]) will pick
> up the one shipped with Autoconf instead of what probably anyone would
> actually want to happen in this scenario.
>
> Cheers,
>    Nick
>