Re: Platform specific code and loadable modules
On Oct 10, "Bryan C. Warnock" <[EMAIL PROTECTED]> took up a keyboard and banged out > On Wednesday 10 October 2001 02:39 pm, Dan Sugalski wrote: > > Okay, I'm about to start in on the skeleton for the variable code. One of > > the big intentions here is that variable types can be loaded in on the > > fly. At the moment I'm considering throwing each variable type into its > > own shareable library, which means we need runtime shareable library > > support, which means we need platform-specific code. Wheee. > > > > Anyone care to teach configure.pl how to handle this? I'm thinking > > something like the hints file for a platform defining a filename for the > > platform-specific code (with a fallback to "$^O.c") that it renames to > > platform.c, or something like that, with an empty default.c that's used > > instead. > > We have a collection of these. You might be better off with architecture > directories (that match $^O, maybe?) and a generic fallback. You can > process and copy into the main directory. This also seems like the time to figure out how we can build in support for $^O optimized funcall-switch-goto, etc. A lot more file generation than we have already done, but hey, that's fine. Thoughts? Brent, add this aspect to your stack? Michael -- Michael Fischer 7.5 million years to run [EMAIL PROTECTED]printf "%d", 0x2a; -- deep thought
Re: Platform specific code and loadable modules
On Wednesday 10 October 2001 02:39 pm, Dan Sugalski wrote: > Okay, I'm about to start in on the skeleton for the variable code. One of > the big intentions here is that variable types can be loaded in on the > fly. At the moment I'm considering throwing each variable type into its > own shareable library, which means we need runtime shareable library > support, which means we need platform-specific code. Wheee. > > Anyone care to teach configure.pl how to handle this? I'm thinking > something like the hints file for a platform defining a filename for the > platform-specific code (with a fallback to "$^O.c") that it renames to > platform.c, or something like that, with an empty default.c that's used > instead. We have a collection of these. You might be better off with architecture directories (that match $^O, maybe?) and a generic fallback. You can process and copy into the main directory. > > This also means we're going to need to handle building shareable > libraries, which is an interesting trick to do cross-platform. I think > it's also time to overhaul the makefile builder. Luckily we do *not* need > anything near as convoluted as MakeMaker, which is a good thing. > > Dan > > --"it's like this"--- > Dan Sugalski even samurai > [EMAIL PROTECTED] have teddy bears and even > teddy bears get drunk -- Bryan C. Warnock [EMAIL PROTECTED]
