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

[Akim Demaille]

>>>>> "Paul" == Paul Eggert <address@hidden> writes:

>> But, I would like to see that handled in M4sh, *not* Autoconf.

Paul> I don't fully understand this distinction.  How would you
Paul> implement the change differently for M4sh?

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.
AdHoC, the future-former project of Alexandre, will be integrated into
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 :).

My point is that I think that CVS Autoconf as of today is fixed.
Maybe some more small adjustments will be needed, but I think we are
on the right tracks.


Paul> We shouldn't let our desire to add an unnecessary nicety on
Paul> rare, ancient hosts add significant risk of breaking Autoconf on
Paul> a lot of much more popular modern hosts.

Agreed!!!  But then again, I am not responsible for Sun's lack of
LINENO support, truly modern environments never ever experienced any
problem with my LINENO stuff (no need to answer to this, I know we
don't share the same definition of `modern', and I'm pushing you :).




>> Also, I would like to provide means to specify what are the
>> requirements you'd like to see fulfilled by the new shell (e.g.,
>> functions).

Paul> We could add those features as necessary, but I don't think
Paul> they'll be needed, at least not at first.  

Agreed too.  BTW, that's what I claim for LINENO :P

Paul> What we want, and what most Autoconf users want, is a standard
Paul> environment, and POSIX is clearly the standard.  I don't think
Paul> too many scripts rely on extensions to POSIX; those that do
Paul> typically put "#!/bin/bash" at the top or something like that.
Paul> This issue can be addressed later, if needed.

Yep.


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!?!?!


>> What are you referring to?  If configure.lineno exits somewhere,
>> how could configure survive?

Paul> Configure invokes configure.lineno with something like this:

Paul> . ./configure.line exit 0

Paul> But suppose configure.lineno falls off the end, without exiting.
Paul> Is this really possible?  

Yes, it is.

Paul> I don't know.  But what is that " 0" doing there if not?

Well, if that's the only remaining problem, I'm fine.  To me, since
configure is not set -e, I don't particularly pay attention to the
*last* $?.  Either you catch an error, and then you AS_ERROR,
otherwise it's not an error, just something you don't care about.

But I agree that this exit 0 changes something, something that
probably is never exercised, but that's not a reason not to fix it.

Thanks!