Front page | perl.perl5.porters |
Postings from April 2010
On Thu, 8 Apr 2010, Nicholas Clark wrote:
> On Mon, Apr 05, 2010 at 10:24:39PM +0100, Ben Morrow wrote:
> > Quoth nick@ccl4.org (Nicholas Clark):
> > >
> > > So I can't see how the whole tree can be done this way. Given that DynaLoader
> > > needs XS compilation, and DynaLoader.o needs to be built to build perl,
> >
> > Is there a good reason for this? That is, is there some reason dl_*.c
> > can't just be included in the normal build, rather than an extension? We
> > would still need an ext/DynaLoader/Makefile.PL to do the preprocessing
> > on DynaLoader_pm.PL, but it could become a nonxs module.
>
> Good question, and one I'd not thought of.
> I don't know, but I'm guessing that it's this way because
>
> a: it always was this way
> b: it was historically assumed that it's easier to write XS than to write
> equivalent C code
It's more that it organically grew that way and never changed.
Originally, there was no dynamic loading of any sort. Larry wrote the
first dlopen()-based dynaloader (perl5alpha6 or so, I think). Others soon
contributed versions for other operating systems (e.g. HP/UX, NeXT, etc.).
Since dynamic loading wouldn't work everywhere, it was natural to think
of it as an "extension", and not include it in the normal build.
Certainly that's how I thought of it.
As for the XS vs. C, I don't have any firsthand knowledge. Larry's
original was in XS, and that made sense thinking of it as an extension.
All the others are XS because they copied Larry's original.
These days, we have a stub dl_none.xs implementation, so we do have
something that can be built everywhere. As long as the interface to
embedders doesn't change, I don't see why it couldn't be included in
the normal build.
--
Andy Dougherty doughera@lafayette.edu
Thread Previous
|
Thread Next