From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <2256501d5763ca7585ed7c8a52da5efd@quanstro.net> From: erik quanstrom Date: Tue, 9 May 2006 19:45:42 -0500 To: 9fans@cse.psu.edu Subject: Re: [9fans] impressive MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 4fb97f84-ead1-11e9-9d60-3106f5b1d025 i think your problems miss the point. an explicit portability layer is another name for a virtual os interface. breaking things up on a call-by-call basis creates calls^2 virtual os interfacen. good luck in testing. of course the simple virtual interface is usually too simple to express what the autoconf guys are really after, so they add a level of indirection. the ironic bit about autoconf is that the vast majority of autoconf garbage is dedicated to features that don't make any difference. using the lowest-common denomitor call would work just as well. (and why not, you have to code this case anyway.) it /is/ possible to make stuff portable across many different posixish systems with very little code. p9p really does a nice job. there's some glue, but that's mostly for the thread library and some networking goo. most projects don't need to get that friendly with the hardware. - erik On Tue May 9 16:57:15 CDT 2006, davide+p9@cs.cmu.edu wrote: > The "old way" was to create an explicit portability layer, > with the application running on top of that layer and > one version of the layer for each platform. So each > application would need one expert to maintain the SunOS > blob, one to maintain the HP-UX blob, etc. > > The autoconf approach (following perl's pioneering > configuration infrastructure) was based on the observation > that the 1995 version of the SunOS blob and the 1995 > version of the Irix blob looked somewhat like each other, > especially in the sense that if you looked at the 1998 > version of each the underlying platforms had added many > of the same features. Also, if you looked at the SunOS > blob for one application and the SunOS blob for another > application, they would of course share many similarities. > > So the theory was to ignore platforms and start testing > for *features*, and the hope was that once a *feature* > had been coded for platforms would add the feature over > time and all software using autoconf would automatically > start using the feature. Great!