From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Tue, 27 Oct 2009 12:16:13 -0400 To: 9fans@9fans.net Message-ID: In-Reply-To: <509071940910270910m5682f735l75b50ef55cea4d30@mail.gmail.com> References: <06a0be10-d05e-47f4-bebf-c9d9512de2b8@q14g2000vbi.googlegroups.com> <636733be-5009-4311-97ab-dc81634dbd06@p15g2000vbl.googlegroups.co> <509071940910270910m5682f735l75b50ef55cea4d30@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Two suggestions for ape (was: egrep for Plan9) Topicbox-Message-UUID: 919a99e8-ead5-11e9-9d60-3106f5b1d025 > // Since the purpose of ape is to emulate the environment > // configure is expected to run in... > > false premise. the purpose of ape is to provide an ANSI/POSIX environment. > it's purpose is as much for outbound porting as inbound, and maintaining the > actual target is more important in that direction. > > the purpose of *conf* is to match the environment it finds itself in. as such, > submitting modifications to that is clearly the correct long-term plan. you're > correct that modifications to *conf* won't help already-distributed packages, > but that seems like not a very good reason to give up the nicely specified > target for ape ("ANSI/POSIX Environment" being a lot easier to define > than "Whatever-Gnu-Assumes-This-Week Environment"). having something > else, > not ape, targeted at broader compatibility might also be useful (some people > have complained about ape's need for defining symbols to use non-ANSI > libraries, for example), but it's a different enough objective that it > ought to be > a different thing (GAPE?). there were a lot of wierd os people talking to a lot of package maintainers at google this weekend. the solution that made sense to *BOTH* was to ditch autoconf and submit a platform specific makefile. it seems we find ourselves exactly in the situation we were in in 1992. the existing portability hacks don't work. and when they don't work they become counter productive. - erik