[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Broken makefile given Autoconf version mismatch

From: Keith Marshall
Subject: Re: Broken makefile given Autoconf version mismatch
Date: Sun, 16 Apr 2006 11:45:07 +0100

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 

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
             ...' ...`

(i.e. with explicit newlines separating the sed command strings).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]