configure m4 problem

[Ozkan Sezer]

On Thu, Aug 19, 2010 at 11:15 AM, Niels Möller <nisse at lysator.liu.se> wrote:
> Ozkan Sezer <sezeroz at gmail.com> writes:
>
>> This is what I got from our builders / configury maintainers:
>>
>> "The configure script is running flex using a nonexistent M4.
>> That causes a sigpipe, which leaves a useless orphaned file.
>> The configure script looks at that and says "ok, flex works".
>> Under python, sigpipe gets filtered out.  So, flex cleans up
>> after itself (as it should), thus deleting the file, and so
>> the configure script thinks flex is broken (when in reality,
>> the configure script is wrong and flex reported correctly.)
>> M4 can't be defined before running AM_PROG_LEX, and it should
>> not be defined al all in that fashion, either."
>
> As far as I see, the configure script does not explicitly start any m4
> when testing for flex. Also, it does not export the M4 variable.
>
> My best guess is that
>
> 1. M4 is for some reason exported into the environment before configure
>   is started.
>
> 2. The value is then changed by configure.
>
> 3. Flex then inherits the modified value (although neither the
>   documentation nor strings indicates that flex examines $M4).
>
> You could try adding an
>
>  unexport M4
>
> to the configure script to see if that makes any interesting difference.
>
> Regards,
> /Niels
>

M4 is a configure user variable and it is supposed to be exported.
See the generated configure file, it is in ac_subst_vars. Although
the GMP_PROG_M4 respects user-set M4 variable, GMP's configure.in
doesn't respect it and override it if $found_asm != yes, which is
not what a configury should do and is wrong.  The original report
at http://permalink.gmane.org/gmane.comp.lib.gmp.bugs/2114 suggests
moving M4 setting lines after AM_PROG_LEX and it seems reasonable.
(Well, AM_PROG_LEX & co can be moved before it, too, I guess.)
Can you please tell us what is wrong with the suggested solutions?

--
Ozkan