Re: [MacPerl] installing libraries in mac perl

[Chris Nandor <pudge@pobox.com>]

At 3:17 +0900 1999.10.22, robinmcf@altern.org wrote:
>*takes a deep breath*perhaps (starts digging a foxhole) might I suggest
>insted of having a seperate POD for where Mac may differ from DOS/VMS/Unix
>(ie  that system() doesn't work unless you have toolserver etc, or comand
>line switches that don't work) why not put this information into the
>relevant points of the Docs thus making forays into PODs a lot less window
>intensive and less time consuming?

That is what perlport.pod is for.  Familiarize yourself with it and you
will be fine.  If you hit a trap that isn't in there, let perlport's
maintainer know.

There are far too many things little from far too many platforms that
change far too often to put the exceptions in the docs themselves.  It
makes the docs more unwieldy and harder to read and maintain.  And
distributing different versions of the docs with MacPerl is, as far as I am
concerned, entirely unacceptable; that is a good way to make a lot of
people mad, both the readers of the docs and the maintainers.  When I tell
a user "look at the entry for Foo in Bar.pod", they should have the exact
same text I do, no matter what platform it is, as long as it is the same
version of perl.

So it was decided to make a separate document, and we got perlport.  It has
served us well so far.  The general tack the docs have been taking is to
point to perlport.  perlfunc lists functions that may differ from platform
to platform, and points to perlport in that section.  The binmode, flock,
kill, pack, and rename entries in perlfunc point to perlport.  (This is as
of 5.005_62.)

It makes it simple, too.  "What platform issues do I need to be aware of
when porting a script to Win32?"  Well, read perlport, and you should have
most of the info you need.  It is really a document everyone should be
quite familiar with (and I don't say that just because I wrote much of it).


>if it's down to the fact the greater Perl community won't like the docs
>being /hacked | cobbled together | messed about with | broken/ then I
>suggest calling them something else (it worked for The Artist Who Was
>Formerly Known As Prince) and covertly distrubuting them :). Seriously
>though there are issues we should deal with, instead of thinking of MacPerl
>as perl on the Mac (read evolved Unix glue language on a Mac) we should be
>thinking about what it has become SINCE it was ported, it shares a heritage
>but much in the way bears and dogs do - common ancestors different beasts -
>so is the bear manual workable as the dog manual and vice versa?

I don't want that.  I don't want something else other than Perl on the Mac.
I want Perl on my Mac, and won't work on something else.  I see no reason
to think of MacPerl as something other than Perl on the Mac, and I
certainly have no desire for it to be something else.  Maybe the problem is
in how you defined Perl.  It is not an evolved Unix glue language.  It is a
full-fledged general programming language.

-- 
Chris Nandor          mailto:pudge@pobox.com         http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10  1FF77F13 8180B6B6'])

# ===== Want to unsubscribe from this list?
# ===== Send mail with body "unsubscribe" to macperl-request@macperl.org