Re: __m4_version__ and frozen files

[Ralf Wildenhues]

Hi Eric,

* Eric Blake wrote on Tue, Aug 26, 2008 at 03:24:32PM CEST:
> My perl is not as strong as my m4; does this patch look sane?

> Subject: [PATCH] Don't let frozen __m4_version__ break downgrade to m4 1.4.x.
> 
> * bin/autom4te.in: Adjust comments, now that we rely on 1.4.5+.
> (files_to_options): Avoid inheriting __m4_version__ from frozen
> file if current M4 does not support it.

> @@ -255,6 +234,12 @@ sub files_to_options (@)
>        if ($file =~ /\.m4f$/)
>       {
>         $arg = "--reload-state=$arg";
> +       # If the user downgraded M4 from 1.6 to 1.4.x after freezing
> +       # the file, then we ensure the frozen __m4_version__ will
> +       # not cause m4_init to make the wrong decision about the
> +       # current M4 version.
> +       $arg .= " --undefine=__m4_version__"
> +         unless grep {/__m4_version__/} @m4_builtin;
>       }
>        push @res, $arg;
>      }

Is it intentional that you add the --undefine after every frozen file?
I suppose m4 evaluates arguments in the order given?  Perusing m4.info,
it seems that -U is evaluated after any reloading has taken place, so
you can limit yourself to undefining __m4_version__ once.  Instead of
appending to $arg, you could also just push another argument to @res
right away, too, which maybe looks a bit cleaner.

Fine with me otherwise.

Thanks,
Ralf