Re: AC_PROG_SED selecting correct sed for config.status

[Albert Chin]

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 Makefile.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
> 
> AC_DEFUN([_AC_OUTPUT_CONFIG_STATUS],
> [AC_REQUIRE([AC_PROG_SED])dnl
> AC_MSG_NOTICE([creating $CONFIG_STATUS])...

I like this solution better.

-- 
albert chin (address@hidden)