On 24 Jun 2007, at 04:54, Noah Misch wrote:
I have a vague memory that once (?) there was an independent m4, and
GNU making their own version gm4. The development of m4 was dropped,
so that GNU could take over the name m4.
M4 is a standard tool from the early Unix days; at a minimum, we
have the
original implementation, PD M4, and GNU M4. Some installers choose
to prefix
GNU program names with `g' on systems that began with non-GNU
tools. There has
never been a reason to do this on the GNU system, where the GNU
program provides
the principal implementation.
The current algorithm is in autoconf's m4/m4.m4:
AC_PATH_PROGS([M4], [gm4 gnum4 m4], [m4])
AC_CACHE_CHECK([whether m4 supports accurate traces],
...
In other words, during configuration, autoconf finds the first
program on
your PATH named gm4, gnum4, and then m4, which also meets the
minimum
requirements of m4 1.4.5 or later. If you have suggestions for a
better
algorithm, we'd like to know about it.
This sounds like a fine algorithm, but it not the one that the
above code
implements. Rather, the code finds the first program so-named and
checks
whether that one program meets the version requirement. It does
not continue
the search upon rejecting a candidate.
The problem is really that the when getting the error, it is hard to
figure out what is causing it. Without that information, workarounds
are of little help. This might simplify if the full path of the
program is written out in the error message.
Another question is to figure out a search method so one does not get
an error message, except when there actually is no up-to-date GNU M4
installed. Given the many ways M4 can be configured, the method seems
to be to search for all three names gm4 gnum4 m4, getting the version
for each and selecting the most recent GNU M4. If that is not
sufficiently up-to-date for Autoconf, an error message should be
issued, with the full paths of the M4 versions it found and examined.
A bit more complicated, but probably not very difficult to implement.
Hans Aberg
