Re: reexec and M4sh (Was: bison-1.29c 'configure' problems on Solaris 8)

[Paul Eggert]

> From: Akim Demaille <address@hidden>
> Date: 05 Oct 2001 11:05:37 +0200
> 
> I saw you had AC_MSG etc. macros.  These belong to the Autoconf
> world.  M4sh is the portable shell script layer, M4sugar is the
> extended m4 macros set.  Autotest and Autoconf are on top of M4sh.
> 
> M4sh shall not depend upon any AC_ things.

> Paul> But my point is that autoconf 2.52e does not work in Solaris 8
> Paul> and probably many other hosts, due to this attempt to support
> Paul> LINENO on a few ancient hosts.  
> 
> Your point is that two days ago CVS Autoconf was like that.  I try to
> avoid naming it 2.52e, as it seems to mean it's a released beta.  It
> does not exist (btw, this is also why I didn't put it on alpha :).

OK.  But it's was bit confusing to call that file 2.52e then.
(At least, I was confused.  :)

> My point is that I think that CVS Autoconf as of today is fixed.

Unfortunately it's not.  It fails on Solaris 8, with similar symptoms.

$ sh configure
configure: test: argument expected
$ sh -x configure
+ test -n  
+ test -n  
+ echo configure 
+ sed s,\(.*[\/]\+\)\?\([^\/]\+\)[\/]*,\2, 
as_me=configure
as_lineno_1=
as_lineno_2=
as_lineno_3=
+ test x = x 
as_save_IFS=    

IFS=
IFS=    

+ test -z 
/net/knick/home/eggert/bin:/opt/reb/bin:/opt/reb/sbin:/usr/krb5/bin:/usr/krb5/sbin:/usr/bin:/usr/sbin:/usr/perl5/5.00503/bin:/usr/ccs/bin:/usr/dt/bin:/usr/openwin/bin:/opt/sfw/bin:/opt/sfw/sbin:/usr/apache/bin:/opt/informix/bin:/opt/frame/bin:/opt/SUNWspro/bin:/opt/SUNWut/bin:/opt/SUNWut/sbin:/usr/proc/bin:/sbin
 
+ test -r 
/net/knick/home/eggert/bin:/opt/reb/bin:/opt/reb/sbin:/usr/krb5/bin:/usr/krb5/sbin:/usr/bin:/usr/sbin:/usr/perl5/5.00503/bin:/usr/ccs/bin:/usr/dt/bin:/usr/openwin/bin:/opt/sfw/bin:/opt/sfw/sbin:/usr/apache/bin:/opt/informix/bin:/opt/frame/bin:/opt/SUNWspro/bin:/opt/SUNWut/bin:/opt/SUNWut/sbin:/usr/proc/bin:/sbin/configure
 
+ test ! -f 
configure: test: argument expected


> Paul> If there were a large number of such machines, I would agree
> Paul> with you.  But nowadays such machines are so rare that they're
> Paul> not worth spending a lot of time to support.
> 
> Paul, you're torturing me.  If that was that easy, then why the heck
> don't we use functions!?!?!

Because if we used functions, the shell scripts simply would not work
on those ancient machines.  But if we use $LINENO, the shell scripts
will work correctly; the only problem is that, when they don't work,
the error messages will say "unknown line" or "line 0" or something
like that.  That behavior is not perfect, but it's good enough to get
the job done.

Much GNU software works better with GCC: it's either more efficient,
or it has better compile-time error-checking, or whatever.  That's
fine, so long as the software still works acceptably with non-GCC
platforms.  It's a similar situation.