On Thu, 15 Nov 2001, James Mastros wrote: > Hey all. > This implements a platforms system similar to what we were discussing > earlier: each interface is a sepperate file, independent of the others, the > hints file specifies what interfaces we use. This does create a large > number of files, but minimizes code copying. All the peices are cated > (effectively) together into a platform.c file. (We could make this a > platform.h, if we want stuff to inline more easily.)
I like the idea of splitting out some things (such as dynaloading) into separate directories, instead of a single monolithic platform.c file. Whether *every* non-portable function needs its own directory is a different question. I suspect not, but it's clearly a matter of taste and balance just where to draw the line. The biggest conceptual problem I saw was this (encountered on Solaris): Nobody has rewritten the "hints" file for your platform yet, and nobody has written the configuration guesser yet. Write a file hints/solaris.pl, using the existing files as examples if your platform is fairly normal, it shouldn't be too hard. I see what you are doing and why you are doing it, but I think creating hints/linux.pl at this point to do these tasks is a very bad precedent. For my longer rant on this subject, see my earlier patch to this list where I removed platform/linux.[ch] in favor of the nearly identical platform/generic.[ch]. You really need to keep some sort of fall-back generic files. Finally, there actually is a mostly-working Configuration guesser already -- just look up the answers in Perl5's Config hash. For example, $Config{d_dlopen} will tell you if the system has the dlopen() function. $Config{so} will give you the shared library suffix, etc. If you use those Config values now, it'll enable you exercise the dynamic construction of platform.[ch] from all the little pieces. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042