Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

perlsource.pod: Misleading discussion of what should go into ext/ #13475

Closed
p5pRT opened this issue Dec 17, 2013 · 17 comments
Closed

perlsource.pod: Misleading discussion of what should go into ext/ #13475

p5pRT opened this issue Dec 17, 2013 · 17 comments

Comments

@p5pRT
Copy link

p5pRT commented Dec 17, 2013

Migrated from rt.perl.org#120808 (status was 'resolved')

Searchable as RT120808$

@p5pRT
Copy link
Author

p5pRT commented Dec 17, 2013

From @jkeenan

I posed this question on perl.perl5porters earlier this year and got no
responses -- except one from rjbs asking me if I had received any
responses and suggesting an RT if I had not. Hence, ...

pod/perlsource.pod describes the 'ext/' directory in the Perl 5
distribution thus​:

#####
=item * F<ext/>

This directory contains XS-using modules which are only released as
part of the core. These modules generally have their F<Makefile.PL> and
are laid out more like a typical CPAN module.
#####

This is misleading because (as of my last count in May 2013), there are
35 subdirectories underneath ext/ of which only 28 have XS. The 7
subdirs which do *not* have XS are​:

Errno
FileCache
IPC-Open3
Pod-Functions
Pod-Html
Tie-Memoize
Win32CORE

My sense is that, until relatively recent times, 'ext/' always held
modules with XS. That's certainly the simplest interpretation of the
first sentence in the paragraph from perlsource.pod quoted above.

Note that in the following paragraph in perlsource.pod, we have this​:

#####
=item * F<dist/>

This directory is for dual-life modules where the blead source is
canonical. Note that some modules in this directory may not yet have
been released separately on CPAN.
#####

It seems to me that the 7 non-XS using libraries under ext/ could just
as easily be described as "not yet [having] been released separately on
CPAN" -- which would mean that they would fit better under dist/ than ext/.

If we can get a decision on what the layout should be, I will either​:
(a) revise the description of 'ext/' to de-emphasize the XS-using part
of it; or (b) set about moving the 7 non-XS using modules to 'dist/'.

Choose!

Thank you very much.
Jim Keenan

Now, I could certainly live with a description of 'ext/' as holding
libraries with a CPAN-style directory and file layout not maintained or
distributed on CPAN. That wouldn't be a very elegant description, and
it would sever the tie between 'ext' and 'eXternal Subroutine'. But it
would be more accurate than what we have now. And this wouldn't require
us to move any libraries from one of the subdirs to another.

@p5pRT
Copy link
Author

p5pRT commented Dec 17, 2013

From @jkeenan

$ perl -V
Summary of my perl5 (revision 5 version 18 subversion 0) configuration​:
 
  Platform​:
  osname=darwin, osvers=8.11.0, archname=darwin-2level
  uname='darwin macintosh-9.local 8.11.0 darwin kernel version 8.11.0​: wed oct 10 18​:26​:00 pdt 2007; root​:xnu-792.24.17~1release_ppc power macintosh powerpc '
  config_args='-des'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=undef, usemultiplicity=undef
  useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
  use64bitint=undef, use64bitall=undef, uselongdouble=undef
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='cc', ccflags ='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe -I/usr/local/include -I/opt/local/include',
  optimize='-O3',
  cppflags='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe -I/usr/local/include -I/opt/local/include'
  ccversion='', gccversion='4.0.1 (Apple Computer, Inc. build 5250)', gccosandvers=''
  intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
  ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
  alignbytes=8, prototype=define
  Linker and Libraries​:
  ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' -L/usr/local/lib -L/opt/local/lib'
  libpth=/usr/local/lib /opt/local/lib /usr/lib
  libs=-ldbm -ldl -lm -lc
  perllibs=-ldl -lm -lc
  libc=, so=dylib, useshrplib=false, libperl=libperl.a
  gnulibc_version=''
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
  cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup -L/usr/local/lib -L/opt/local/lib'

Characteristics of this binary (from libperl)​:
  Compile-time options​: HAS_TIMES PERLIO_LAYERS PERL_DONT_CREATE_GVSV
  PERL_HASH_FUNC_ONE_AT_A_TIME_HARD PERL_MALLOC_WRAP
  PERL_PRESERVE_IVUV PERL_SAWAMPERSAND USE_LARGE_FILES
  USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE
  USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF
  Built under darwin
  Compiled at May 18 2013 12​:31​:26
  %ENV​:
  PERLBREW_BASHRC_VERSION="0.59"
  PERLBREW_HOME="/Users/jimk/.perlbrew"
  PERLBREW_MANPATH=""
  PERLBREW_PATH="/Users/jimk/perl5/perlbrew/bin"
  PERLBREW_ROOT="/Users/jimk/perl5/perlbrew"
  PERLBREW_VERSION="0.59"
  @​INC​:
  /usr/local/lib/perl5/site_perl/5.18.0/darwin-2level
  /usr/local/lib/perl5/site_perl/5.18.0
  /usr/local/lib/perl5/5.18.0/darwin-2level
  /usr/local/lib/perl5/5.18.0
  /usr/local/lib/perl5/site_perl/5.16.0
  /usr/local/lib/perl5/site_perl/5.14.2
  /usr/local/lib/perl5/site_perl/5.14.0
  /usr/local/lib/perl5/site_perl/5.12.0
  /usr/local/lib/perl5/site_perl/5.10.1
  /usr/local/lib/perl5/site_perl/5.10.0
  /usr/local/lib/perl5/site_perl/5.8.6
  /usr/local/lib/perl5/site_perl
  .

@p5pRT
Copy link
Author

p5pRT commented Dec 17, 2013

From @cpansprout

On Mon Dec 16 19​:24​:18 2013, jkeen@​verizon.net wrote​:

It seems to me that the 7 non-XS using libraries under ext/ could just
as easily be described as "not yet [having] been released separately on
CPAN" -- which would mean that they would fit better under dist/ than ext/.

At least to me, the main distinction between dist and ext is that code under dist needs to work with older versions, whereas we can do whatever we like (use new shiny features) with ext. Maybe that could be incorporated into a new description for ext.

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Dec 17, 2013

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Dec 17, 2013

From @bulk88

On Mon Dec 16 19​:24​:18 2013, jkeen@​verizon.net wrote​:

I posed this question on perl.perl5porters earlier this year and got no
responses -- except one from rjbs asking me if I had received any
responses and suggesting an RT if I had not. Hence, ...

pod/perlsource.pod describes the 'ext/' directory in the Perl 5
distribution thus​:

#####
=item * F<ext/>

This directory contains XS-using modules which are only released as
part of the core. These modules generally have their F<Makefile.PL> and
are laid out more like a typical CPAN module.
#####

This is misleading because (as of my last count in May 2013), there are
35 subdirectories underneath ext/ of which only 28 have XS. The 7
subdirs which do *not* have XS are​:

Errno
FileCache
IPC-Open3
Pod-Functions
Pod-Html
Tie-Memoize
Win32CORE

My sense is that, until relatively recent times, 'ext/' always held
modules with XS. That's certainly the simplest interpretation of the
first sentence in the paragraph from perlsource.pod quoted above.

Note that in the following paragraph in perlsource.pod, we have this​:

#####
=item * F<dist/>

This directory is for dual-life modules where the blead source is
canonical. Note that some modules in this directory may not yet have
been released separately on CPAN.
#####

It seems to me that the 7 non-XS using libraries under ext/ could just
as easily be described as "not yet [having] been released separately on
CPAN" -- which would mean that they would fit better under dist/ than ext/.

If we can get a decision on what the layout should be, I will either​:
(a) revise the description of 'ext/' to de-emphasize the XS-using part
of it; or (b) set about moving the 7 non-XS using modules to 'dist/'.

Choose!

Thank you very much.
Jim Keenan

Now, I could certainly live with a description of 'ext/' as holding
libraries with a CPAN-style directory and file layout not maintained or
distributed on CPAN. That wouldn't be a very elegant description, and
it would sever the tie between 'ext' and 'eXternal Subroutine'. But it
would be more accurate than what we have now. And this wouldn't require
us to move any libraries from one of the subdirs to another.

Win32CORE has a .c files with xsubs. So it basically has XS.

Pod-Html should be on CPAN or dual lifed. Pod-Html, which is used by ActivePerl for their pretty (CSSed) HTML docs, suffered some bug fixes and some regressions between 5.14 and 5.16. I'm not sure where to even file a ticket, or if it can ever be fixed since Pod-Html is not distributed on CPAN and therefore isn't upgradable.
--
bulk88 ~ bulk88 at hotmail.com

@p5pRT
Copy link
Author

p5pRT commented Dec 17, 2013

From @tonycoz

On Mon Dec 16 19​:24​:18 2013, jkeen@​verizon.net wrote​:

Now, I could certainly live with a description of 'ext/' as holding
libraries with a CPAN-style directory and file layout not maintained or
distributed on CPAN. That wouldn't be a very elegant description, and
it would sever the tie between 'ext' and 'eXternal Subroutine'. But it
would be more accurate than what we have now. And this wouldn't require
us to move any libraries from one of the subdirs to another.

I believe this is the correct way to handle it.

On Mon Dec 16 22​:53​:48 2013, bulk88 wrote​:

Pod-Html should be on CPAN or dual lifed. Pod-Html, which is used by
ActivePerl for their pretty (CSSed) HTML docs, suffered some bug fixes
and some regressions between 5.14 and 5.16. I'm not sure where to even
file a ticket, or if it can ever be fixed since Pod-Html is not
distributed on CPAN and therefore isn't upgradable.

I don't think anyone would object to you packaging Pod-Html for CPAN.

Tony

@p5pRT
Copy link
Author

p5pRT commented Dec 20, 2013

From @rjbs

* Tony Cook via RT <perlbug-followup@​perl.org> [2013-12-17T17​:57​:53]

On Mon Dec 16 22​:53​:48 2013, bulk88 wrote​:

Pod-Html should be on CPAN or dual lifed. Pod-Html, which is used by
ActivePerl for their pretty (CSSed) HTML docs, suffered some bug fixes
and some regressions between 5.14 and 5.16. I'm not sure where to even
file a ticket, or if it can ever be fixed since Pod-Html is not
distributed on CPAN and therefore isn't upgradable.

I don't think anyone would object to you packaging Pod-Html for CPAN.

I would owe the packager a beer, juice, or other beverage or snack.

--
rjbs

@p5pRT
Copy link
Author

p5pRT commented Dec 20, 2013

From @jkeenan

On 12/19/13 9​:34 PM, Ricardo Signes wrote​:

* Tony Cook via RT<perlbug-followup@​perl.org> [2013-12-17T17​:57​:53]

On Mon Dec 16 22​:53​:48 2013, bulk88 wrote​:

Pod-Html should be on CPAN or dual lifed. Pod-Html, which is used by
ActivePerl for their pretty (CSSed) HTML docs, suffered some bug fixes
and some regressions between 5.14 and 5.16. I'm not sure where to even
file a ticket, or if it can ever be fixed since Pod-Html is not
distributed on CPAN and therefore isn't upgradable.

I don't think anyone would object to you packaging Pod-Html for CPAN.

I would owe the packager a beer, juice, or other beverage or snack.

The discussion has gone a bit off topic. I'd like to discuss Pod-Html,
but in a separate thread. So, too get back on topic, let me ask​:

rjbs​: Do you have feedback on my OP on pod/perlsource.pod and on Father
C's and Tony's comments?

Thank you very much.
Jim Keenan

@p5pRT
Copy link
Author

p5pRT commented Feb 10, 2014

From @rjbs

On Fri Dec 20 12​:55​:22 2013, jkeen@​verizon.net wrote​:

rjbs​: Do you have feedback on my OP on pod/perlsource.pod and on Father
C's and Tony's comments?

Yes​: I agree with your suggestion and with FC's elaboration.

--
rjbs

@p5pRT
Copy link
Author

p5pRT commented Feb 11, 2014

From @jkeenan

On Mon Feb 10 14​:47​:51 2014, rjbs wrote​:

On Fri Dec 20 12​:55​:22 2013, jkeen@​verizon.net wrote​:

rjbs​: Do you have feedback on my OP on pod/perlsource.pod and on Father
C's and Tony's comments?

Yes​: I agree with your suggestion and with FC's elaboration.

Okay, then let's get concrete. Please evaluate the patch attached. (I'll apply it to blead in 7 days unless there is an objection.)

Thank you very much.
Jim Keenan

@p5pRT
Copy link
Author

p5pRT commented Feb 11, 2014

From @jkeenan

120808-0001-Clarify-distinction-between-contents-of-dist-and-ext.patch
From 549fcc75f5665e162dd09e8d3eb5e5a66f69f428 Mon Sep 17 00:00:00 2001
From: James E Keenan <jkeenan@cpan.org>
Date: Tue, 11 Feb 2014 01:50:47 +0100
Subject: [PATCH] Clarify distinction between contents of dist/ and ext/.

For: RT #120808
---
 pod/perlsource.pod |   21 +++++++++++++--------
 1 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/pod/perlsource.pod b/pod/perlsource.pod
index 81e3e94..aa351dd 100644
--- a/pod/perlsource.pod
+++ b/pod/perlsource.pod
@@ -46,15 +46,20 @@ their tests, unlike other core modules.
 
 =item * F<ext/>
 
-This directory contains XS-using modules which are only released as
-part of the core. These modules generally have their F<Makefile.PL> and
-are laid out more like a typical CPAN module.
+Like F<lib/>, this directory contains modules which are only released
+as part of the core.  Unlike F<lib/>, however, a module under F<ext/>
+generally has a CPAN-style directory- and file-layout and its own
+F<Makefile.PL>.  There is no expectation that a module under F<ext/>
+will work with earlier versions of Perl 5.  Hence, such a module may
+take full advantage of syntactical and other improvements in Perl 5
+blead.
 
 =item * F<dist/>
 
 This directory is for dual-life modules where the blead source is
 canonical. Note that some modules in this directory may not yet have
-been released separately on CPAN.
+been released separately on CPAN.  Modules under F<dist/> are expected
+to work with earlier versions of Perl 5.
 
 =item * F<cpan/>
 
@@ -118,10 +123,10 @@ other directories.
 
 =item * F<t/opbasic/>
 
-Tests for perl's built in functions which, like those in F<t/op/>, do not fit
-into any of the other directories, but which, in addition, cannot use
-F<t/test.pl>,as that program depends on functionality which the
-test file itself is testing.
+Tests for perl's built in functions which, like those in F<t/op/>, do
+not fit into any of the other directories, but which, in addition,
+cannot use F<t/test.pl>,as that program depends on functionality which
+the test file itself is testing.
 
 =item * F<t/re/>
 
-- 
1.7.1

@p5pRT
Copy link
Author

p5pRT commented Feb 15, 2014

From @rjbs

On Mon Feb 10 18​:29​:49 2014, jkeenan wrote​:

Okay, then let's get concrete. Please evaluate the patch attached.
(I'll apply it to blead in 7 days unless there is an objection.)

Looks fine to me.

If I were to pick a nit, it would be this​:

+been released separately on CPAN. Modules under F<dist/> are expected
+to work with earlier versions of Perl 5.

I might say "will often work" or "should make an effort to work." The language "are expected" makes me wonder "expected by whom?" and whether it implies any obligation. I don't think there is a blanket obligation to support earlier perls, but that it we should not gratuitously cease to support them.

At any rate, the patch is a marked improvement on the accuracy of the documentation.

--
rjbs

@p5pRT
Copy link
Author

p5pRT commented Feb 16, 2014

From @karenetheridge

On Mon, Feb 10, 2014 at 06​:29​:49PM -0800, James E Keenan via RT wrote​:

Okay, then let's get concrete. Please evaluate the patch attached. (I'll apply it to blead in 7 days unless there is an objection.)

With these changes, will it be possible to distinguish (in, say,
Module​::CoreList) whether a module is dual-lifed or not by looking at which
directory it lives in?

If yes, it would also be useful to enforce the directory distinctions by
testing if particular modules are indexed by PAUSE, and whether the
associated distribution is its own dual-lifed distribution or the latest
stable perl release. I would be happy to write a patch if someone can
suggest where such a test should live and when it would run.

@p5pRT
Copy link
Author

p5pRT commented Feb 16, 2014

From @jkeenan

On Sun Feb 16 13​:28​:10 2014, perl@​froods.org wrote​:

On Mon, Feb 10, 2014 at 06​:29​:49PM -0800, James E Keenan via RT wrote​:

Okay, then let's get concrete. Please evaluate the patch attached.
(I'll apply it to blead in 7 days unless there is an objection.)

With these changes, will it be possible to distinguish (in, say,
Module​::CoreList) whether a module is dual-lifed or not by looking at
which
directory it lives in?

No.

But that's no change from the current situation, where dual-lifed modules may exist in either cpan/ or dist/.

My patch is just a documentation patch and does not move any modules from one tree to another. The objective is simply to describe the contents of the various trees more accurately than pod/perlsource.pod does now.

Thank you very much.
Jim Keenan

@p5pRT
Copy link
Author

p5pRT commented Feb 17, 2014

From @jkeenan

On Fri Feb 14 18​:06​:56 2014, rjbs wrote​:

On Mon Feb 10 18​:29​:49 2014, jkeenan wrote​:

Okay, then let's get concrete. Please evaluate the patch attached.
(I'll apply it to blead in 7 days unless there is an objection.)

Looks fine to me.

If I were to pick a nit, it would be this​:

+been released separately on CPAN. Modules under F<dist/> are
expected
+to work with earlier versions of Perl 5.

I might say "will often work" or "should make an effort to work." The
language "are expected" makes me wonder "expected by whom?" and
whether it implies any obligation. I don't think there is a blanket
obligation to support earlier perls, but that it we should not
gratuitously cease to support them.

At any rate, the patch is a marked improvement on the accuracy of the
documentation.

Patch, incorporating rjbs's suggestion, was applied to blead in commit 259799c.

Closing ticket. Any other issues concerning the directory structure should be raised on p5p list or in a new RT.

Thank you very much.
Jim Keenan

@p5pRT
Copy link
Author

p5pRT commented Feb 17, 2014

@jkeenan - Status changed from 'open' to 'resolved'

@p5pRT p5pRT closed this as completed Feb 17, 2014
@p5pRT
Copy link
Author

p5pRT commented Feb 17, 2014

From @steve-m-hay

On 16 February 2014 21​:27, Karen Etheridge <perl@​froods.org> wrote​:

On Mon, Feb 10, 2014 at 06​:29​:49PM -0800, James E Keenan via RT wrote​:

Okay, then let's get concrete. Please evaluate the patch attached. (I'll apply it to blead in 7 days unless there is an objection.)

With these changes, will it be possible to distinguish (in, say,
Module​::CoreList) whether a module is dual-lifed or not by looking at which
directory it lives in?

If yes, it would also be useful to enforce the directory distinctions by
testing if particular modules are indexed by PAUSE, and whether the
associated distribution is its own dual-lifed distribution or the latest
stable perl release. I would be happy to write a patch if someone can
suggest where such a test should live and when it would run.

My understanding was that a module is dual-lived if and only if it has
a DISTRIBUTION field in Porting/Maintainers.pl. (I have no idea
whether that information is available via Module​::CoreList, though.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant