Re: Broken makefile given Autoconf version mismatch

2006-04-16 Thread Paul Eggert
Keith Marshall <[EMAIL PROTECTED]> writes: > This requirement is reflected in the SunOS man page, (from SunOS 5.5.4, > IIRC) Hmmm, "SunOS 5.5.4"? There's no such version. The Sun 'sed' pages that I looked at (from SunOS 5.8 and SunOS 5.10) don't require that _every_ command be separated by new

Re: Broken makefile given Autoconf version mismatch

2006-04-16 Thread Paul Eggert
Stepan Kasal <[EMAIL PROTECTED]> writes: > semicolons cannot be used inside > curly braces, so you have to write, for example: > > sed '/datarootdir/{ > p > q > }' > > IIRC, Autoconf was recently fixed to obey this rule, Yes, here: http://lists.gnu.org/archive/html/autoconf-patch

Re: Broken makefile given Autoconf version mismatch

2006-04-16 Thread Noah Misch
On Sun, Apr 16, 2006 at 12:58:08PM +0200, Alexandre Duret-Lutz wrote: > I'm leery of assuming that Autoconf's version will always be at > this spot in the output of --version. Sometimes people customize their > copy and tweak --version to reflect so: > > % gcc --version > gcc (GCC) 4.0.3 (Debian

Re: Broken makefile given Autoconf version mismatch

2006-04-16 Thread Keith Marshall
On Sunday 16 April 2006 7:36 pm, Stepan Kasal wrote: > Second, let me remind me that we are currently in a freeze; I believe > that this type of changes should be put off after 2.60, unless it is > supported by a real-world problem report. I wasn't suggesting that you should immediadely rush to ch

Re: Broken makefile given Autoconf version mismatch

2006-04-16 Thread Stepan Kasal
Hello, On Sun, Apr 16, 2006 at 12:58:08PM +0200, Alexandre Duret-Lutz wrote: > [...] --version really is a human thing in my opinion. > > Anyway it sure feels better to directly compare the value of > m4_PACKAGE_VERSION in one Autoconf with the value of > m4_PACKAGE_VERSION in another, without t

Re: Broken makefile given Autoconf version mismatch

2006-04-16 Thread Stepan Kasal
Hello, On Sun, Apr 16, 2006 at 06:58:28PM +0100, Keith Marshall wrote: > On Sunday 16 April 2006 1:41 pm, Andreas Schwab wrote: > > Keith Marshall <[EMAIL PROTECTED]> writes: > > > On Wednesday 12 April 2006 8:47 pm, Stepan Kasal wrote: > > > > We both use the same pattern > > > > `sed -n '/@

Re: Broken makefile given Autoconf version mismatch

2006-04-16 Thread Andreas Schwab
Keith Marshall <[EMAIL PROTECTED]> writes: > Let me turn that around, and ask if you can provide any documentary > evidence, other than anecdotal, to suggest that this use of semicolons > *should* be supported? SUSv3 *expressly* demands that sed directives be > separated by newlines: > http://w

Re: Broken makefile given Autoconf version mismatch

2006-04-16 Thread Keith Marshall
On Sunday 16 April 2006 1:41 pm, Andreas Schwab wrote: > Is there any evidence that there exists a sed implementation that does > not support the semicolon as command separator?  Note that the thread > you quote above is _not_ about semicolons being unsupported, but rather > about missing ones.  Au

Re: Broken makefile given Autoconf version mismatch

2006-04-16 Thread Keith Marshall
On Wednesday 12 April 2006 8:47 pm, Stepan Kasal wrote: > On Wed, Apr 12, 2006 at 08:45:04PM +0200, Ralf Wildenhues wrote: > > here's a patch that I think does more or less what Bruno's patch > > intends to do, against current CVS. > > I worked on the same issue.  We both use the same pattern >    

Re: Broken makefile given Autoconf version mismatch

2006-04-16 Thread Andreas Schwab
Keith Marshall <[EMAIL PROTECTED]> writes: > On Wednesday 12 April 2006 8:47 pm, Stepan Kasal wrote: >> On Wed, Apr 12, 2006 at 08:45:04PM +0200, Ralf Wildenhues wrote: >> > here's a patch that I think does more or less what Bruno's patch >> > intends to do, against current CVS. >> >> I worked on

Re: Broken makefile given Autoconf version mismatch

2006-04-16 Thread Alexandre Duret-Lutz
>>> "SK" == Stepan Kasal <[EMAIL PROTECTED]> writes: SK> Hello, SK> On Thu, Apr 13, 2006 at 08:52:48PM +0200, Alexandre Duret-Lutz wrote: >> Or can we tweak Autoconf to make its version more accessible? SK> what would be wrong with parsing `autoconf --version' or SK> `autom4te --version'? (