In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Andy Dougherty) wrote:
> On Fri, 2 Nov 2001, Jason Diamond wrote: > > > Then we could have a "driver" for each platform that consisted of > > nothing > > but #include's of other .c files. Making a directory for each > > platform might > > be appropriate if we do this. I bet that most of the posix "platform" > > source > > files would be #include'ed into each of the more specific drivers. > > But one big problem is you can't even name all the platforms! New > platforms appear all the time that you never heard of, and Parrot might > work perfectly well on them, but you don't even know of the platform's > existence at release time. > > Certainly platform-specific files are needed sometimes, but I've not > seen > anything that convinces me that a linux.c file does anything but open > the > floodgates to a maintenance job of maintaining lots of nearly-identical > files. I think the answer is not to assume 2 files (.c&.h) for each platform[1]. Rather a pool of files which configure picks from for the local platform (i.e. something has to know that Ynix uses Solaris like async-io while Znix uses Sys5 like async-io). For some platforms more will be needed (VMS being an obvious example) for others (*ix) fewer. On a previous project this is what I ended up with (some aspects of the systems were very different, some quite close). Which brings me around to the initial build of miniperl (to drive the full configure) which surely doesn't need most of the system dependent functions (e.g. no async-io, only the most simple of time/date functions). Having got a "largely platform independent build" perl we can then perform some data driven operations to work out (1) which modules to include, (2) build some headers (e.g. "platform.h" that includes the selected headers) and (3) what tools and options to use for the build. The question is where to draw the line between the different sub-platform files. (And quite possibily part of the answer is to share files where there are just minor differences[2]). [1] This also avoids having huge files for supporting platforms which need substantial code to achieve Perl6's common "OS abstraction layer". [2] E.g. Use RIO_FAST on one platform and R_IOFAST on another, but used in the same way. -- [EMAIL PROTECTED]
