Re: extensions/known_extensions and insanity (was Re: VMS, configure.com and nonxs_ext)

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.

> Hence if you have not built some XS extensions on your platform  
> (which, I
> think, is always true, as you can't build both VMS and Win32  
> extensions
> anywhere), there will always be something in known_extensions that  
> is not
> in extensions.
>
> Likewise, if you *have* build something nonxs (which you have do, as  
> you can't
> build DynaLoader without (at least) ExtUtils::ParseXS), there will  
> always be
> something in extensions that isn't in known_extensions.
>
> Good, eh?
>
> 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.


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.

________________________________________
Craig A. Berry
mailto:[email protected]

"... getting out of a sonnet is much more
  difficult than getting in."
                  Brad Leithauser