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
