[Top][All Lists]

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

Re: AC_PROG_SED selecting correct sed for config.status

From: Albert Chin
Subject: Re: AC_PROG_SED selecting correct sed for config.status
Date: Wed, 29 Dec 2004 17:04:35 -0600
User-agent: Mutt/1.5.6i

On Wed, Dec 29, 2004 at 11:11:17PM +0100, Stepan Kasal wrote:
> on a second thought, I see an alternate approach:
> > > Have you encountered any problem on a particular platform?
> > 
> > Yes. When building kdevelop from kde-3.3.2 on Solaris 2.6, 7,
> > substitions in's with long lines gets truncated resulting
> > in a dead build.
> Well, to encounter this problem you need a system which:
> 1) has a broken sed
> 2) is powerful enough to be used for complex packages, loke KDE, which
>    produce long substitutions
> It is perfectly possible that this juxtaposition appears only on Solaris.

It doesn't appear on HP-UX, Tru64 UNIX, IRIX, nor AIX.

> So we can as well go along the following:
> if we are on Solaris and the default awk or sed is not POSIX compatible
>       if  /usr/xpg4/bin/sed is available
>               AC_MSG_WARN([Sane people have /usr/xpg4/bin in the
>                       begining of their path])
>               PATH="/usr/xpg4/bin:$PATH"
>       else
>               AC_MSG_WARN([Solaris without /usr/xpg4/bin is like
>                       Linux without GNU.])
>       fi
> fi
> The resulting ./configure script will complain on misconfigured Solaris
> systems.  You may call it ``educating people'' or ``bothering people'',
> acording to your mood.
> This would also bring a sane awk to the configure script, so if a macro
> uses awk, it has a better chance to work.
> I'd like to hear opinions on which approach is better.

Prepending /usr/xpg4/bin to $PATH is likely to open up more problems.
It's not the default on Solaris. And, probably for good reason (i.e.
default behaviour is not what a typical Solaris user might expect).

> And now for something completely different:
> > Yep. I cannot AC_REQUIRE([AC_PROG_SED]) in a m4_define'd macro.
> If your approach wins, I'd suggest

I like this solution better.

albert chin (address@hidden)

reply via email to

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