On Sun, Sep 27, 2009 at 03:04:38PM -0500, Craig A. Berry wrote: > > On Sep 27, 2009, at 1:26 PM, Nicholas Clark wrote: > > >I *think I am here: > > > >0: DynaLoader doesn't count as an extension > >1: known_extensions are all known XS extensions > >2: static_ext, dynamic_ext and nonxs_ext are actually what they say > >they are, > > assuming you were thinking about "extensions we have configured > >here" > >3: extensions is the sum of the 3 immediately above > > I think we are now accurately imitating this on VMS except that > DynaLoader is not currently listed in extensions.
No, that's quite correct: $ grep Dyna config.sh $ > >As an encore, the Unix Configure script teases you with -Dnoextensions > >to disable extensions, but only actually honours it for XS extensions. > >Right know it assumes that all nonxs extensions will work everywhere. > > Most likely that's because once upon a time, saying "XS extension" was > redundant and saying "non-XS extension" was a non-sequitur. And while > we might expect Camel 3 and Extending and Embedding Perl to be out-of- > date when they exclusively use the word "extension" to talk about > extending Perl with C code, the current discussions in perlxs and > perlxstut do the same thing. perlfaq7 gets even more explicit and says, > > =head2 What's an extension? > > An extension is a way of calling compiled C code from Perl. Reading > L<perlxstut> is a good place to learn more about extensions. Thanks for that analysis. I wasn't aware of that. > With that definition of what an extension is, choosing -Dnoextensions > to skip just the XS modules makes perfect sense. > > So I think one of the places where we went wrong was in introducing > "nonxs_ext" for pure-Perl modules that are not properly called > extensions. Maybe it should have been "built_modules" or "built_pm" > or similar, and "extensions" would have been "modules" (though further > distinctions between built modules and included modules might be > necessary). > > This may be of purely hysterical interest as changing %Config entries > now would probably cause more trouble than it would avoid, but > hopefully it helps explain why we have some of the oddities that we do. Yes, that's pretty much my view now. We can also "add" new ones, or a whole new scheme, but really we need ot think it through carefully, and assume we have exactly this chance to get it "right". Forever. Or until the special biologist word catches up with us. Nicholas Clark
