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, [EMAIL PROTECTED] 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!
