Re: name of m4 executable

[Marco Franzen]

[Crossposting to gcc-bugs. 
Gcc's top-level Makefile invokes sub-makes with M4=m4. This overrides
autoconf's otherwise correct idea of what "m4" it should call.]

On Sat, 21 Oct 2000, Assar Westerlund wrote:
> Marco Franzen <address@hidden> writes:
> > When I configured autoconf, it looked for GNU m4 under serveral names,
> > including gm4:
> >     checking for gm4... /usr/gnu/bin/gm4
> > After building and installing autoconf, this information was lost, and the
> > installed version did not find this very (g)m4.
> 
> It should have.  It does code this into the generated autoconf
> sh-script:
> 
> : ${M4=/usr/gnu/bin/gm4}
> : ${AWK=awk}
> case "${M4}" in
> /*) # Handle the case that m4 has moved since we were configured.
>     # It may have been found originally in a build directory.
>     test -f "${M4}" || M4=m4 ;;
> esac
> 
> Where the value of M4 in the first line should be the one that it
> found during configure.  Can you check in your installed autoconf
> script to see what it says?

Yes, it says exactly that.
 
> The only reason for it not to work, would be that it triggers the code
> in the case, namely that the script cannot find the m4 that was found
> at configure time.  Can you check if this is the case?

Actually, the reason was different. I would call it a bug in gcc.

The top-level Makefile of gcc apparently tries to override m4 (for
autoconf or for something else) with any other m4 that might be present in
the current build tree. But the default case (no m4 in the tree) hard-codes
overriding with the value `m4' (without the quotes) rather than not
overriding.

The Makefile sets (literally copied from its Makefile.in)
DEFAULT_M4 = m4
M4 = `if [ -f $$r/m4/m4 ] ; \
        then echo $$r/m4/m4 ; \
        else echo ${DEFAULT_M4} ; fi`

The correct solution would be not to override, but that is not trivial
from a Makefile. It would be easier to set it to the empty string, but that
does not work with the installed autoconf currently doing
        : ${M4=/path/to/known/gnu-m4}
(without a colon before the equals sign).

I was not aware that that override facility existed in autoconf. Is that a
documented feature? Did Gcc actually try to use it or does it set the
environment variable for something else than autoconf.

I am not sure if autoconf should be changed. If so, it might ignore the
value of the environment variable if it does not point to GNU m4 (like it
currently checks only later after any overriding) and maybe issue a
warning when it falls back to its configured-in default for this reason.

On gcc's side, it is still wrong to override m4 with a hard-coded value
(other than maybe the empty string if that worked). At the very least, if it
must override it at all, then it should search for suitable m4's at
configuration time the same way autoconf does.

Autoconf could help this if it provided a way of telling its default, like
`autoconf --print-m4-path' might just say it. But that would not help gcc
testers with existing versions of autoconf.

> /assar

Marco

PS: The only reason why I am using autoconf here at all is that the
published diffs to patch up gcc snapshot tarballs don't always include diffs
for the autoconf-generated files. (The diff from 1002-1009 example lacked
"libstdc++/configure" but changed its "configure.in".) They don't include
diffs for bison-generated files either. My wishlist for that apparent
weekly script would be:

- Get the timestamps in the tarball right, so that testers don't need
  autoconf, bison, etc. 

- Include changes to generated files in the diffs, and include them *after*
  the diffs to their sources so that the timestamps after patching are
  right.

The fake script named "missing" does not help if diffs are missing, and it
does not help with wrong timestamps either in some cases because it does
not support the way of invoking bison the way it is invoked by gcc
makefiles.
-----------------------------------------------------------------
This email is confidential and intended solely for the use of the
individual to whom it is addressed.
Any views or opinions presented are solely those of the author
and do not necessarily represent those of Thyron Limited.
If you are not the intended recipient then please be advised
that you have received this email in error and that any use,
dissemination, forwarding, printing or copying of this email
is strictly prohibited.
If you have received this email in error, please notify the
Thyron IT Administrator on +44 (0)1923 236 050 or
send an email to address@hidden
Thank You