From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <4AE5BAE4.9040203@conducive.org>
Date: Mon, 26 Oct 2009 23:06:12 +0800
From: W B Hacker <wbh@conducive.org>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
	rv:1.8.1.23) Gecko/20090823 SeaMonkey/1.1.18
MIME-Version: 1.0
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
References: <636733be-5009-4311-97ab-dc81634dbd06@p15g2000vbl.googlegroups.com>
	<813b8c20-849c-4fae-b856-770824e4a038@u13g2000vbb.googlegroups.com>
In-Reply-To: <813b8c20-849c-4fae-b856-770824e4a038@u13g2000vbb.googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [9fans] Two suggestions for ape
Topicbox-Message-UUID: 903e957c-ead5-11e9-9d60-3106f5b1d025

Dmitry Golubovsky wrote:
> On Oct 26, 9:21Â am, 23h...@googlemail.com (hiro) wrote:
>>> Since the purpose of ape is to emulate the environment configure is
>>> expected to run in, and such mismatch has been found, it migh be
>>> easier to fix ape than to convince maintaners of autoconf to fix on
>>> their side...
>> Why are you so sure they wouldn't fix it? Have you or has anybody you
>> know tried something like this already?
>
> Because even if they fix it in the current (or perhaps the nearest
> future) version (in repos now) of autoconf this would not apply
> retroactively to previous/current versions everyone has.
>
> Besides, one thing (very long regexp to match all ASCII letters and
> numbers in a CPP directive - see the thread on awk incompatibility) is
> done on purpose: they specifically wanted to avoid character ranges
> (perhaps wrt some locales where a-z range might also include letters
> with diacritics, but this is only my guess). Regexp buffer length
> limitation in Plan9 awk may be more fundamental problem.
>
> Well, these problems arise only if one wants to have a port for Plan9
> share the sources with upstream (hence to have common configure
> scripts, Makefiles, tools, etc.)
>
> If a fork-style port for Plan9 is considered then of course everything
> may be adjusted properly (like configure is not needed at all because
> there is only one
> configuration, etc.).
>
> Thanks.
>
>

A problem is being made without looking at proven solutions.

NEITHER the 'upstream' port NOR Plan9 should be radically changed.

Why risk breakage or future problems in EITHER?

Nor is it necessary to 'fork' the build system.

Just provide Plan9-specific patch(es), and a line or two for the configure (or
directly into the Makefile) that checks for a Plan9 environment, makes the
relevant adjustments (dirtrees are important, too) and sucks in the appropriate
patch(es).

Look, for example, at any of a very large number of FreeBSD ports. Most carry a
small patch set added by the FreeBSD-specific port maintainer.

In this case, the needful stuff was offered earlier in the thread. It could be
used to alter the behaviour of awk - but only for the life of that build
process, needing no change to the original sources OR Plan9's 'normal'
behaviour.

I cite FeeBSD, if for no other reason than their huge count of ports -  but
'awk' is hardly the only issue, and some form of that need is also found w/r
AIX, Solaris, HP UX and several others - not to mention Linux and BSD 'flavors'
as build targets, so it is hardly new ground.

CAVEAT: Expect some need for education upstream. Not everyone is aware that
Plan9 is still among the living.

;-)

JM2CW

Bill