Front page | perl.perl5.porters |
Postings from June 2013
[perl #118537] Add non-XS extensions to known_extensions
Thread Next
From:
Nicholas Clark
Date:
June 19, 2013 09:25
Subject:
[perl #118537] Add non-XS extensions to known_extensions
Message ID:
rt-3.6.HEAD-2552-1371633931-1655.118537-75-0@perl.org
# New Ticket Created by Nicholas Clark
# Please include the string: [perl #118537]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=118537 >
I think that we should change Configure so that known_extensions includes
non-XS extensions. Currently, not having the non-XS modules in
known_extensions means that unlike XS modules, you can't skip building any
non-XS module, as t/TEST and t/harness will always run their tests (which
will fail), because the extension-test-skip logic uses known_extensions.
This means that
1) you can't elect not to build to-be-evicted modules
2) we can't put any platform-specific modules in ext (eg VMS::Filespec)
If we change things so that known_extensions includes the nonxs_ext, then
both of the above are solved.
I don't think that it will break anything - grep.cpan.me suggests that there
are only 10 non-core mentions of known_extensions, and none of them rely on
this existing behaviour.
Right now we have the wonderfully inconsistent situation (for
Configure-generated config.sh) of
dynamic_ext: built dynamically linked XS modules
static_ext: built statically linked XS modules
nonxs_ext: built pure-Perl modules (from ext/, dist/ and cpan/)
extensions: "$dynamic_ext $static_ext $nonxs_ext"
known_extensions: *just* the XS modules shipped in ext/, dist/ and cpan/
ie "extensions" is typically much larger than "known_extensions"
Moreover, I believe that we're inconsistent between platforms, in that on
Win32, "known_extensions" has everything.
This situation has come about through "organic growth", rather than design.
I guess it's summarised as
0) Perl 5 predates CPAN
1) Originally Perl 5 only shipped with XS code in ext/
2) Originally there was no concept of dual-life - if you wanted the
extensions in ext/, you had to build them with perl
3) 15 years ago (today), Configure was patched to add nonxs_ext
(commit 4318d5a0158916ac) ready to support Errno
(Errno was added about two weeks later in commit eab60bb1f2e96e20)
[curiously that commit adds Errno to known_extensions but not to
extensions]
4) A few days later commit bfb7748a896459cc updates Configure so that
nonxs_ext *are* in extensions, but are *not* in known_extensions.
The description of the change is:
Explicitly split list of extensions into 3 kinds: dynamic, static,
and non-xs. The Configure variable $extensions now holds all three.
(The only current non-xs extension is Errno).
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1998-07/msg00136.html
It also updates Porting/Glossary, explicitly changing the description
of known_extensions from "list of all extensions included" to
"list of all XS extensions included", and extensions from
"all extension files linked into the package" to
"all extension files (both XS and non-xs linked into the package."
[oooh, that lack of closing ) is still present today]
[Note that Errno *is* architecture specific, so gets installed into the same
directory subtree as all the shared object]
Fast forward from 1998 to 2006
5) Commit 1d8961043b9b86e1 (or thereabouts) in April 2006 regenerates the
sample config.sh to this:
nonxs_ext='Compress/IO/Base Compress/IO/Zlib Compress/Zlib Errno'
at which point, we have 3 more non-XS extensions, all of which are
architecture independent.
Subsequent re-arranging of dual-life modules in 2009 means that we've got a
lot more.
Effectively, the term "extensions" has been meaning "things we build via
Makefile.PL" for at least 7 years, if not 15.
Even though perlfaq7 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.
which was added when the FAQ was added by commit 68dc074516a6859e back in
March 1997 in the run-up to 5.004, and has only had style changes since then.
That must be one of the most Infrequently Asked Questions out there.
(the above is partly based on explanations from Craig Berry in
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2009-09/msg00688.html )
So I think it's sane to apply the attached 3 patches (which have been on a
smoke-me quite happily), amended with this change to the Glossary:
diff --git a/Porting/Glossary b/Porting/Glossary
index b57f990..08a5020 100644
--- a/Porting/Glossary
+++ b/Porting/Glossary
@@ -2666,7 +2666,7 @@ expr (Loc.U):
extensions (Extensions.U):
This variable holds a list of all extension files (both XS and
- non-xs linked into the package. It is propagated to Config.pm
+ non-xs) installed with the package. It is propagated to Config.pm
and is typically used to test whether a particular extension
is available.
@@ -3620,8 +3620,8 @@ ivtype (perlxv.U):
This variable contains the C type used for Perl's IV.
known_extensions (Extensions.U):
- This variable holds a list of all XS extensions included in
- the package.
+ This variable holds a list of all extensions (both XS and non-xs)
+ included in the package.
ksh (Loc.U):
This variable is defined but not used by Configure.
I believe that the behaviour is win32/FindExt.pm is already this way.
I don't know enough to edit configure.com to change it.
Nicholas Clark
Thread Next
-
[perl #118537] Add non-XS extensions to known_extensions
by Nicholas Clark