Re: bison-1.29c 'configure' problems on Solaris 8.
Gary == Gary V Vaughan [EMAIL PROTECTED] writes: Gary As far as shell functions are concerned, it seems to me that Gary m4sh could provide shell function wrapper macros which expand to Gary a function/function call if that is supported by the shell, or Gary else an inline function if not... Something which creates satellites executables (small sh scripts instead of functions) when functions are not supported? I often thought about that. Gary Then again, perhaps I am the only one who finds symbolic Gary debugging of shell scripts to be useful ;-) I think it's a cute idea. Never used it yet though.
Re: bison-1.29c 'configure' problems on Solaris 8.
On Fri, Oct 19, 2001 at 06:00:38PM +0200, Akim Demaille wrote: Gary == Gary V Vaughan [EMAIL PROTECTED] writes: Gary As far as shell functions are concerned, it seems to me that Gary m4sh could provide shell function wrapper macros which expand to Gary a function/function call if that is supported by the shell, or Gary else an inline function if not... Something which creates satellites executables (small sh scripts instead of functions) when functions are not supported? I often thought about that. I am sure it would work, and perhaps it would encourage people with broken shells to install bash... but somehow adding a couple of hundred little scripts to the libtool run time fills me with fear! Gary Then again, perhaps I am the only one who finds symbolic Gary debugging of shell scripts to be useful ;-) I think it's a cute idea. Never used it yet though. I had ambitions to integrate it into ddd (which already handles perl for example). Unfortunately bash's implementation of the DEBUG trap is not powerful enough to support full debugging written in shell, so I plan to add some better support for symbolic debugging directly into bash one day. Cheers. Gary. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook =`---d__/
Re: bison-1.29c 'configure' problems on Solaris 8.
Paul == Paul Eggert [EMAIL PROTECTED] writes: From: Akim Demaille [EMAIL PROTECTED] Date: 04 Oct 2001 17:31:18 +0200 First let's find a portable LINENO, *then* move to another shell. Paul But the attempt to find a portable LINENO is not cost-free. Paul It is broken now, and it will take time to fix it, and this is Paul time that will be almost entirely wasted in practice once we Paul execute configure with a portable shell. So am I understanding that LINENO is a POSIX feature? The current implementation in CVS Autoconf might be broken, but really, I fail to understand what makes you fear the LINENO stuff that much. Why do you say it is broken? What is the *current* problem? Raja says it works fine on Solaris 8. I'm referring to CVS Autoconf, of course. Paul These days, almost nobody runs on systems that lack portable Paul shells. I wouldn't spend a lot of time worrying about these Paul rare, ancient systems, particularly as the LINENO feature is not Paul essential for proper operation of configure. I definitely agree!!! That's exactly what I'm doing! I'm moving at getting more and more new shell features into Autoconf, but I can't see that LINENO stuff being that bad. If you do think we should drop it, and I'm not strictly against that decision, but very reluctant, then I would really like to have the opinion of the comaintainers. People, the question is: If we look for a reasonable shell and re-exec configure once we found one, are you OK with keeping $LINENO used in configure, even if the shell does not treat $LINENO specially? *And*, keep in mind the decision involves M4sh too (i.e., Autotest scripts, M4sh-AdHoC scripts and so on).
Re: bison-1.29c 'configure' problems on Solaris 8.
On Fri, Oct 05, 2001 at 10:56:04AM +0200, Akim Demaille wrote: People, the question is: If we look for a reasonable shell and re-exec configure once we found one, are you OK with keeping $LINENO used in configure, even if the shell does not treat $LINENO specially? *And*, keep in mind the decision involves M4sh too (i.e., Autotest scripts, M4sh-AdHoC scripts and so on). There might be problems with re-execing to get a shell that has a feature that you want... invariably, the shell that you use will be *lacking* a feature that someone else wants. I wrote a section about finding a shell that supports functions for the Goat Book: http://sources.redhat.com/autobook/autobook/autobook_214.html#SEC214 But when I tried to add this to libtool, it conflicted with libtool's requirement for a shell that doesn;t mangle backslash escapes. ISTR that there were several systems that couldn;t provide a shell that supplied both :-( In this instance I could have fallen back on using libtool's --fallback-echo, but it felt as though this was moving in the wrong direction... As far as shell functions are concerned, it seems to me that m4sh could provide shell function wrapper macros which expand to a function/function call if that is supported by the shell, or else an inline function if not... although `trap DEBUG' doesn't work very well for functions, so my bashdb debugger will be considerably less effective if shell functions come into common use for configury. Then again, perhaps I am the only one who finds symbolic debugging of shell scripts to be useful ;-) Cheers, Gary. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook =`---d__/
Re: bison-1.29c 'configure' problems on Solaris 8.
Hi, Akim! People, the question is: If we look for a reasonable shell and re-exec configure once we found one, are you OK with keeping $LINENO used in configure, even if the shell does not treat $LINENO specially? *And*, keep in mind the decision involves M4sh too (i.e., Autotest scripts, M4sh-AdHoC scripts and so on). Fine with me as long as the testsuite doesn't break. I understand that it doesn't. -- Regards, Pavel Roskin
Re: bison-1.29c 'configure' problems on Solaris 8.
From: Akim Demaille [EMAIL PROTECTED] Date: 05 Oct 2001 10:56:04 +0200 So am I understanding that LINENO is a POSIX feature? Yes. The current implementation in CVS Autoconf might be broken, but really, I fail to understand what makes you fear the LINENO stuff that much. Why do you say it is broken? What is the *current* problem? The latest problem is what happens when you type control-C when you are generating configure.lineno. My guess is that there will be more problems. Raja says it works fine on Solaris 8. I'm referring to CVS Autoconf, of course. After I checked in a regenerated 'configure', I think it probably works on Solaris 8 if your environment is OK. But I suspect we'll run into more problems later, as people run it with different environment variables, or on different hosts. People, the question is: If we look for a reasonable shell and re-exec configure once we found one, are you OK with keeping $LINENO used in configure, even if the shell does not treat $LINENO specially? I don't quite understand the question as worded. Here's how I would word the question: Suppose we change configure so that, if invoked with a shell that does not support LINENO, it first looks for a shell that supports LINENO and re-executes configure with that shell. This should avoid the LINENO problem on all major operating systems shipped in the last seven years or so. (SunOS 4.1.4, the last major holdout, shipped in November 1994.) If we do this, is it still worth the aggravation of maintaining code to substitute LINENO ourselves, for older hosts like SunOS 4.1.4 that have no shell that supports LINENO? The advantage of substituting for LINENO is that configure failures will have nice-looking line numbers even on older hosts. This advantage applies only when configure fails. The disadvantage is that the LINENO-substituting code does not work in all cases now, will hardly ever be exercised, and will probably continue to have bugs indefinitely.
