Re: Broken makefile given Autoconf version mismatch
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'? (At least as a fallback, when autom4te is SK not able to handle stdin.) 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 4.0.3-1) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This sounds legitimate for me. --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 trying to infer any of them. SK The problem is that autom4te calls m4 with `/dev/null' because of a SK problem with a development version of m4: SK 2001-09-07 Akim Demaille SK * bin/autom4te.in (handle_m4): ` /dev/null' so that GNU M4 1.5 SK doesn't neutralize SIGINT, making autoconf etc. non interruptible. That was around the time caching was introduced, so I presume that the interaction between the cache and reading stdin has never been considered. I think it should disable cache for stdin, since it cannot check its timestamp. I'm starting to think now is probably not the right time to try to fix this. Nobody is actually missing this to the point it should delay 2.60. (I'm only speaking of the stdin issue here; the version check in aclocal can be implemented independently.) SK I posted a question to m4-discuss asking whether this concern is still SK valid for the not-yet-released m4 2.0. SK There is a related problem: SK autom4te -l Autoconf-without-aclocal-m4 - SK still wouldn't work, because find_file doesn't recognize `-' as stdin. autoconf wouldn't pass any argument as far as I can tell. SK What do you think about the patch to find_file attached below? This has implications on the caching code, which tries to mtime() all arguments. Really this is too early. How about adding syntactic sugar only after it can be supported? -- Alexandre Duret-Lutz Shared books are happy books. http://www.bookcrossing.com/friend/gadl
Re: Broken makefile given Autoconf version mismatch
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 the same issue. We both use the same pattern `sed -n '/@datadir@/p;/@docdir@/p;/@infodir@/p...' ...` I'd like, if I may, to sound a note of caution concerning this sed command syntax: the use of semicolons as command separators in the sed script is an implementation dependent extension, which is not portable. On some platforms, the test using this sed syntax *will* fail, not because the feature you are testing is unsupported, but because the test itself is invalid. In November 2005, Robert Goulding posted these bug reports on groff@gnu.org: http://lists.gnu.org/archive/html/groff/2005-11/msg4.html http://lists.gnu.org/archive/html/groff/2005-11/msg00074.html It turns out that Robert was having a problem building CVS groff, which requires texinfo = 4.8 to compile the info files, under Mac OS X, and configure was saying his texinfo was too old, in spite of him having explicitly just installed texinfo-4.8. The actual problem was that the configure test employed a sed command with this same semicolon usage, and was not behaving as expected -- the test failed because *it* was invalid, *not* because the detected texinfo was too old! 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. Autoconf is using semicolons in sed expressions already for many years (eg in the AC_OUTPUT_FILES macro). Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: Broken makefile given Autoconf version mismatch
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 `sed -n '/@datadir@/p;/@docdir@/p;/@infodir@/p...' ...` I'd like, if I may, to sound a note of caution concerning this sed command syntax: the use of semicolons as command separators in the sed script is an implementation dependent extension, which is not portable. On some platforms, the test using this sed syntax *will* fail, not because the feature you are testing is unsupported, but because the test itself is invalid. In November 2005, Robert Goulding posted these bug reports on groff@gnu.org: http://lists.gnu.org/archive/html/groff/2005-11/msg4.html http://lists.gnu.org/archive/html/groff/2005-11/msg00074.html It turns out that Robert was having a problem building CVS groff, which requires texinfo = 4.8 to compile the info files, under Mac OS X, and configure was saying his texinfo was too old, in spite of him having explicitly just installed texinfo-4.8. The actual problem was that the configure test employed a sed command with this same semicolon usage, and was not behaving as expected -- the test failed because *it* was invalid, *not* because the detected texinfo was too old! At this time, I checked the man page for sed on a SunOS box. Here the documentation very explicitly states that commands in sed scripts *must* be separated by newlines; semicolon is acceptable as an alternative to a comma, to separate the two components of a range specification, but it is *not* acceptable as a command separator. Curiously, the SunOS sed implementation *does* support semicolons as command separators, even though the man page expressly excludes it; it would seem, however, that Mac OS X may be more rigorous in this requirement. To guarantee portability of the above sed command, it cannot be written as shown: `sed -n '/@datadir@/p;/@docdir@/p;/@infodir@/p...' ...` it *must* be rewritten as: `sed -n -e '/@datadir@/p' -e '/@docdir@/p' -e '/@infodir@/p' ...` or as: `sed -n '/@datadir@/p /@docdir@/p /@infodir@/p ...' ...` (i.e. with explicit newlines separating the sed command strings). Regards, Keith.
Re: Broken makefile given Autoconf version mismatch
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://www.opengroup.org/onlinepubs/009695399/utilities/sed.html
The command can be preceded by blanks and/or semicolons. The function
can be preceded by blanks. These optional characters shall have no
effect.
Command verbs other than {, a, b, c, i, r, t, w, :, and # can be followed
by a semicolon, optional blanks, and another command verb.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
Re: Broken makefile given Autoconf version mismatch
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 '/@datadir@/p;/@docdir@/p;/@infodir@/p...' ...`
first, let me correct my own posting. My version of the patch, which
was then installed doesn't happen to contain semicolons as command
separators. (Search for @datadir@ in autoconf-2.59c/configure.)
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.
[...] the use of semicolons as command separators in the sed
script is an implementation dependent extension, which is not portable.
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. Autoconf is using semicolons in sed expressions
already for many years (eg in the AC_OUTPUT_FILES macro).
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://www.opengroup.org/onlinepubs/009695399/utilities/sed.html
The link contains the following text:
| Command verbs other than {, a, b, c, i, r, t, w, :, and # can be
| followed by a semicolon, optional blanks, and another command verb.
| However, when the s command verb is used with the w flag, following it
| with another command in this manner produces undefined results.
which means that the above code would be portable.
But looking to the text, you can see that its distinction between
functions and commands implies that 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, even though I don't
think a platform was found which wouldn't handle
sed '/datarootdir/{;p;q;}'
So we really don't ``bury our heads in the sand'' when we notice that
we are depending on a feature which is not promised by POSIX.
(BTW, note that
sed '/datarootdir/{p
}'
is correct according to POSIX, yet I think some implementations are not
able to parse it.)
Oh, and yes, I do know of at least one sed implementation which
definitely does not support the use of semicolons as command separators;
however, since it is one I wrote myself, for bare standard MS-DOS,
running entirely in the real mode 640kB address space, it probably
doesn't carry much weight in this context. :-)
Is this the only missing feature for full POSIX conformance? :-)
Have a nice day,
Stepan Kasal
Re: Broken makefile given Autoconf version mismatch
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 trying to infer any of them. you are right, of course. So processing a file containing m4_PACKAGE_VERSION is the way. I don't know what is better: a temporary file, or a permanently installed one. I'm starting to think now is probably not the right time to try to fix this. Nobody is actually missing this to the point it should delay 2.60. (I'm only speaking of the stdin issue here; the version check in aclocal can be implemented independently.) I supposed that aclocal should be able to find out the version number for older releases of Autoconf. In that case, it would need some workaround for the bug in autom4te anyway. That's why I supposed that the bug in autom4te will be fixed after 2.60, too. SK autom4te -l Autoconf-without-aclocal-m4 - ... SK What do you think about the patch to find_file attached below? This has implications on the caching code, which tries to mtime() all arguments. Really this is too early. How about adding syntactic sugar only after it can be supported? Sure, let's put this off. Stepan
Re: Broken makefile given Autoconf version mismatch
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 change anything;
I was simply alerting you to an apparently related problem we had
encountered in groff, which you might like to bear in mind, for future
reference.
[...] the use of semicolons as command separators in the sed
script is an implementation dependent extension, which is not
portable.
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. Autoconf is using semicolons in sed
expressions already for many years (eg in the AC_OUTPUT_FILES
macro).
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://www.opengroup.org/onlinepubs/009695399/utilities/sed.html
The link contains the following text:
| Command verbs other than {, a, b, c, i, r, t, w, :, and # can be
| followed by a semicolon, optional blanks, and another command verb.
| However, when the s command verb is used with the w flag, following
| it with another command in this manner produces undefined results.
Ah, I overlooked that, sorry. Yet that is not reflected in my SunOS man
page, which explicitly demands that *all* commands, in a multiple command
sequence are separated by newlines; thus, SunOS 5.5.4 does not promise
this level of POSIX compliance, (but I suspect that it does provide it).
which means that the above code would be portable.
Indeed it should be; perhaps the Mac OS X implementation, on which the
original problem was observed, lacks the appropriate level of compliance.
Or, perhaps it was the \+ construct which was the real cause of the
problem; I don't have access to such a system to verify this.
But looking to the text, you can see that its distinction between
functions and commands implies that semicolons cannot be used inside
curly braces, so you have to write, for example:
sed '/datarootdir/{
p
q
}'
And indeed, that is explicitly stated in the reference text.
IIRC, Autoconf was recently fixed to obey this rule, even though I
don't think a platform was found which wouldn't handle
sed '/datarootdir/{;p;q;}'
Yet the reference document expressly forbids that, for `{' is one of
those commands which is *not* permitted to be followed by semicolon and
another command.
So we really don't ``bury our heads in the sand'' when we notice that
we are depending on a feature which is not promised by POSIX.
Perhaps that was an unnecessarily harsh criticism, sorry.
(BTW, note that
sed '/datarootdir/{p
}'
is correct according to POSIX, ...
Are you sure about that? After all `{' and `p' are documented as two
distinct commands, and since `{' cannot be followed by semicolon and
another command, they should surely need a newline to separate them.
... yet I think some implementations are not
able to parse it.)
Which arguably, would be POSIXly correct behaviour.
Oh, and yes, I do know of at least one sed implementation which
definitely does not support the use of semicolons as command
separators; however, since it is one I wrote myself, for bare
standard MS-DOS, running entirely in the real mode 640kB address
space, it probably doesn't carry much weight in this context. :-)
Is this the only missing feature for full POSIX conformance? :-)
Oh, I wouldn't claim POSIX compliance for it; after all MS-DOS isn't a
POSIX compliant OS. At the time I wrote it, I needed a sed like program
which could run on MS-DOS, on an original 8088 PC, (yes 8088 4.7MHz
vintage PC). I modelled it on the sed command description in the Waite
Group's `UNIX System V Bible', published by Howard Sams; IIRC it was a
fairly complete implementation, in terms of its command set. It also
included a reasonable implementation of a regex parser for basic regular
expressions, lacking only the `\{m,n\}' feature, I believe, (and that
probably wouldn't have been too difficult to add, had I a need and the
inclination to do so).
Regards,
Keith.
Re: Broken makefile given Autoconf version mismatch
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 4.0.3-1) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This sounds legitimate for me. --version really is a human thing in my opinion. With respect to `--version' output, GNU Coding Standards state, `The first line is meant to be easy for a program to parse; the version number proper starts after the last space.' Customizing `gcc --version' in this way certainly is common, but it does violate the Coding Standards.
Re: Broken makefile given Autoconf version mismatch
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-patches/2006-01/msg5.html
and CVS Automake was fixed at about the same time:
http://lists.gnu.org/archive/html/automake-patches/2006-01/msg00014.html
sed '/datarootdir/{p
}'
is correct according to POSIX, yet I think some implementations are not
able to parse it.)
Hmm, which would those be? We should probably document the exact
problem in the Autoconf manual. I just checked 7th Edition Unix 'sed'
(dated January 1979) and it worked OK. So these implementations would
either have had a bug introduced, or have been independent of the late
Lee McMahon's original implementation.
Re: Broken makefile given Autoconf version mismatch
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 newlines; only that
commands within { ... } be separated by newlines, which is the POSIX
rule that CVS Autoconf and Automake already conform to.
So (unless I'm missing something) I think we're OK.
Here's the SunOS 5.10 man page:
http://docs.sun.com/app/docs/doc/816-5165/6mbb0m9rv?a=view
