FAQ

[P5P] Suggestions to better ship Perl on OS X.

Michael G Schwern
Nov 11, 2004 at 9:19 am
Hi Ed. I've just gone through putting together a fresh OS X installation
and was reminded of the little nits in Apple's Perl installation that could
use fixing when next they do an upgrade (with Tiger?) I forget who handles
this at Apple, if not you could you please forward this on to whom it may
concern?


1) perldiag.pod is missing from default, diagnostics.pm breaks.

This causes "use diagnostics" to fail. Any code which uses diagnostics.pm
will fail. I tend to notice this when installing Inline.pm.

perldiag.pod is available in the Developer Documentation part of XCode I
believe. I tend to not bother installing that because its nearly a gig
which seems a little silly to get one file.

Recommendation: Since some code will not run without it, move perldiag.pod
into the default Perl installation.

Typical work around: Copy perldiag.pod from 5.8.1 source.


2) perlfunc.pod is missing from default, perldoc -f breaks.

Without perlfunc.pod, perldoc -f will not work.

perlfunc.pod, like perldiag, is available in the very large Developer
Documentation part of XCode. Same problem with perldiag, its silly to
install a gig of docs just to get one file.

Recommendation: Since perldoc is installed by default and it requires
perlfunc.pod to be fully functional, perlfunc.pod should be installed by
default.

Typical work around: Copy perlfunc.pod from 5.8.1 source.


--
Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern/
the chair. it wants to die. oh no! she sees me! she attacks!
reply

Search Discussions

12 responses

  • Andy Lester at Nov 11, 2004 at 4:40 pm

    On Thu, Nov 11, 2004 at 04:19:32AM -0500, Michael G Schwern (schwern@pobox.com) wrote:
    1) perldiag.pod is missing from default, diagnostics.pm breaks.

    2) perlfunc.pod is missing from default, perldoc -f breaks.
    I've got a Tiger build that I can check on, if no one else wants to.

    xoa

    --
    Andy Lester => andy@petdance.com => www.petdance.com => AIM:petdance
  • Edward Moy at Nov 11, 2004 at 5:37 pm
    Yes, I'm still the person. The splitting of the perl (and other
    projects) into different distributions has been a sore point for a long
    time. The historical reason for it was to make a minimum system
    installation fit on the minimum number of CDs. This is of less
    importance now that DVDs are being used for distribution, but still a
    consideration.

    So thanks for reporting the perldiag.pod problem. The problem of pure
    perl modules failing to install because the CORE header files are
    missing (which I assume is still a problem) was on my list to get
    fixed, but I've busy on so many other things.

    Are there any other issues along these lines that I can use as an
    argument to keep perl together? I need to convince the group that does
    the actual packaging of the distributions.

    Edward Moy
    Apple
    On Nov 11, 2004, at 1:19 AM, Michael G Schwern wrote:

    Hi Ed. I've just gone through putting together a fresh OS X
    installation
    and was reminded of the little nits in Apple's Perl installation that
    could
    use fixing when next they do an upgrade (with Tiger?) I forget who
    handles
    this at Apple, if not you could you please forward this on to whom it
    may
    concern?


    1) perldiag.pod is missing from default, diagnostics.pm breaks.

    This causes "use diagnostics" to fail. Any code which uses
    diagnostics.pm
    will fail. I tend to notice this when installing Inline.pm.

    perldiag.pod is available in the Developer Documentation part of XCode
    I
    believe. I tend to not bother installing that because its nearly a gig
    which seems a little silly to get one file.

    Recommendation: Since some code will not run without it, move
    perldiag.pod
    into the default Perl installation.

    Typical work around: Copy perldiag.pod from 5.8.1 source.


    2) perlfunc.pod is missing from default, perldoc -f breaks.

    Without perlfunc.pod, perldoc -f will not work.

    perlfunc.pod, like perldiag, is available in the very large Developer
    Documentation part of XCode. Same problem with perldiag, its silly to
    install a gig of docs just to get one file.

    Recommendation: Since perldoc is installed by default and it requires
    perlfunc.pod to be fully functional, perlfunc.pod should be installed
    by
    default.

    Typical work around: Copy perlfunc.pod from 5.8.1 source.


    --
    Michael G Schwern schwern@pobox.com
    http://www.pobox.com/~schwern/
    the chair. it wants to die. oh no! she sees me! she attacks!
  • Michael G Schwern at Nov 11, 2004 at 9:56 pm

    On Thu, Nov 11, 2004 at 09:36:54AM -0800, Edward Moy wrote:
    So thanks for reporting the perldiag.pod problem. The problem of pure
    perl modules failing to install because the CORE header files are
    missing (which I assume is still a problem) was on my list to get
    fixed, but I've busy on so many other things.
    It sort of is and sort of isn't.

    ExtUtils::MakeMaker has been altered to no longer need perl.h to install
    normal Perl modules. But that version isn't quite stable enough yet for
    core inclusion (my fault) so 5.8.5 is still using the older, perl.h
    dependent version.

    But I haven't seen people having problems with this lately so it doesn't
    seem to be as much of a problem as it was when 10.3 first came out. Maybe
    people know to install the BSD SDK now.

    So it would be nice if perl.h was included by default (the rest aren't so
    important and can remain in the BSD SDK) but its not as important as it was.
    Perhaps BSD SDK should be in the default XCode install. Its small, useful
    and avoids lots of "why don't I have this?" questions.

    Are there any other issues along these lines that I can use as an
    argument to keep perl together? I need to convince the group that does
    the actual packaging of the distributions.
    Not that I can think of. They're relatively minor but so is the fix.
    If just those few files (perlfunc.pod, perldiag.pod and perl.h) were
    kept with the default install things would be ok. If all the header files
    were kept that would be even better, avoiding the BSD SDK confusion.
    The rest of the .pod files aren't necessary and can stay in the developer
    documentation package.


    --
    Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern/
    My beverage utensil experiences a volume crisis.
  • Nicholas Clark at Nov 12, 2004 at 3:40 pm

    On Thu, Nov 11, 2004 at 09:36:54AM -0800, Edward Moy wrote:
    Yes, I'm still the person. The splitting of the perl (and other
    Are there any other issues along these lines that I can use as an
    argument to keep perl together? I need to convince the group that does
    the actual packaging of the distributions.
    This isn't an answer to your question, but more to schwern's original
    subject. I realise that OS X 10.3 is going to stick on its current perl
    binary for the rest of its days. But would it be possible to ship a
    *four byte* change to its Config.pm as part of one of the future security
    upgrades. I assume you know the one :-)

    Change

    ld='MACOSX_DEPLOYMENT_TARGET=10.3 cc'

    to

    ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc'

    in Config.pm


    I fear that the answer is that that change would need too much testing to
    be justifiable. :-(

    Nicholas Clark
  • Yitzchak Scott-Thoennes at Nov 12, 2004 at 10:03 am

    On Thu, Nov 11, 2004 at 04:19:32AM -0500, Michael G Schwern wrote:
    2) perlfunc.pod is missing from default, perldoc -f breaks.

    Without perlfunc.pod, perldoc -f will not work.

    perlfunc.pod, like perldiag, is available in the very large Developer
    Documentation part of XCode. Same problem with perldiag, its silly to
    install a gig of docs just to get one file.

    Recommendation: Since perldoc is installed by default and it requires
    perlfunc.pod to be fully functional, perlfunc.pod should be installed by
    default.

    Typical work around: Copy perlfunc.pod from 5.8.1 source.
    Not an OS X user, but I wonder if the same applies to perldoc -q and
    perlfaq*.pod.
  • Michael G Schwern at Nov 12, 2004 at 5:10 pm

    On Fri, Nov 12, 2004 at 02:03:35AM -0800, Yitzchak Scott-Thoennes wrote:
    Not an OS X user, but I wonder if the same applies to perldoc -q and
    perlfaq*.pod.
    Oooh. Good catch.

    [~] perldoc -q foo
    No documentation found for "perlfaq1".
    No documentation found for "perlfaq2".
    No documentation found for "perlfaq3".
    No documentation found for "perlfaq4".
    No documentation found for "perlfaq5".
    No documentation found for "perlfaq6".
    No documentation found for "perlfaq7".
    No documentation found for "perlfaq8".
    No documentation found for "perlfaq9".

    Ed? Add then to the list.

    Anything else perldoc likes to scan?


    --
    Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern/
    Playstation? Of course Perl runs on Playstation.
    -- Jarkko Hietaniemi
  • Matt Sergeant at Nov 13, 2004 at 7:56 am

    On 12 Nov 2004, at 17:09, Michael G Schwern wrote:

    Anything else perldoc likes to scan?
    Basically *.pod - I'd like to see things like perlguts.pod included -
    there are many times I may be programming in an ssh session to another
    box that I'd like to bring up a local shell for the docs.
  • Michael G Schwern at Nov 13, 2004 at 9:29 am

    On Sat, Nov 13, 2004 at 07:56:40AM +0000, Matt Sergeant wrote:
    Anything else perldoc likes to scan?
    Basically *.pod - I'd like to see things like perlguts.pod included -
    there are many times I may be programming in an ssh session to another
    box that I'd like to bring up a local shell for the docs.
    perlguts (and all the other perl* POD files) is already included as a man
    page.


    --
    Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern/
    It's Ecstacy time!
  • Matt Sergeant at Nov 13, 2004 at 10:22 am

    On 13 Nov 2004, at 09:29, Michael G Schwern wrote:
    On Sat, Nov 13, 2004 at 07:56:40AM +0000, Matt Sergeant wrote:
    Anything else perldoc likes to scan?
    Basically *.pod - I'd like to see things like perlguts.pod included -
    there are many times I may be programming in an ssh session to another
    box that I'd like to bring up a local shell for the docs.
    perlguts (and all the other perl* POD files) is already included as a
    man
    page.
    Yes. Seems kind of daft to exclude the pods then.
  • Alexey Tourbin at Nov 13, 2004 at 10:08 am

    On Thu, Nov 11, 2004 at 04:19:32AM -0500, Michael G Schwern wrote:
    1) perldiag.pod is missing from default, diagnostics.pm breaks.

    This causes "use diagnostics" to fail. Any code which uses diagnostics.pm
    will fail. I tend to notice this when installing Inline.pm.
    Hello,

    I also encountered this problem when splitting perl into RPM packages.
    Here is a workaround:

    --- lib/diagnostics.pm~ 2003-03-17 20:05:08 +0000
    +++ lib/diagnostics.pm 2003-06-10 10:18:04 +0000
    @@ -249,7 +249,8 @@
    }
    }
    if (eof(POD_DIAG)) {
    - die "couldn't find diagnostic data in $PODFILE @INC $0";
    + warn "diagnostics not available (you may want to install perl-pod package)\n";
    + caller() ? return 1 : exit 1;
    }
  • Nicholas Clark at Nov 13, 2004 at 10:20 am

    On Sat, Nov 13, 2004 at 01:08:20PM +0300, Alexey Tourbin wrote:
    On Thu, Nov 11, 2004 at 04:19:32AM -0500, Michael G Schwern wrote:
    1) perldiag.pod is missing from default, diagnostics.pm breaks.

    This causes "use diagnostics" to fail. Any code which uses diagnostics.pm
    will fail. I tend to notice this when installing Inline.pm.
    Hello,

    I also encountered this problem when splitting perl into RPM packages.
    Here is a workaround:

    --- lib/diagnostics.pm~ 2003-03-17 20:05:08 +0000
    +++ lib/diagnostics.pm 2003-06-10 10:18:04 +0000
    @@ -249,7 +249,8 @@
    }
    }
    if (eof(POD_DIAG)) {
    - die "couldn't find diagnostic data in $PODFILE @INC $0";
    + warn "diagnostics not available (you may want to install perl-pod package)\n";
    + caller() ? return 1 : exit 1;
    }
    This patch is wrong, in that does not belong in the core source distribution.
    We don't provide a perl-pod package, why should we reference it?

    If downstream want to split up the core distribution, *they* should put this
    in locally, and provide their correct name for their package.

    Nicholas Clark
  • Rafael Garcia-Suarez at Nov 13, 2004 at 3:11 pm

    Nicholas Clark wrote:

    This patch is wrong, in that does not belong in the core source distribution.
    We don't provide a perl-pod package, why should we reference it?

    If downstream want to split up the core distribution, *they* should put this
    in locally, and provide their correct name for their package.
    /me approves. And while we're at it, I can't help saying that MDK ships pods
    in a perl-doc package, except perldiag.pod, which is in the perl RPM (with
    diagnostics.pm).

Related Discussions