Re: Where is site_perl?

2003-03-10 Thread drieux
On Sunday, Mar 9, 2003, at 19:53 US/Pacific, Vicki Brown wrote:

OK, where is site_perl? ... or the moral equivalent thereof?
[jeeves: 94:] perl -MConfig -e 'print site lib:  
$Config{installsitelib} \nVendor Lib: $Config{installvendorlib}\n'
site lib:  /Library/Perl
Vendor Lib: /Network/Library/Perl
[jeeves: 95:]

This works for both perl on apple, and on *nix boxes.

Given Apple's unusual installation directories, if I have a set of 
.pm's I
need to install (no bundle, no Makefile, I just need to put them in the
right place)... do I put them in /Library/Perl/darwin?
/Library/Perl/darwin/auto?
The real question here is if they are 'pure perl'
without any actual XS stuff, then they are by definition
'architecture independent' and should path from
	/Library/Perl

eg: if I have a package that is

	Foo::Bar::Baz

then I want to make sure that I have constructed the paths

	/Library/Perl/Foo/Bar/

and put that Baz.pm there.

At which point you may wish to correct the core defect here,
which is that your collection of 'perl modules' would be simpler
to manage had you started with say h2xs to simplify the process
of building out your 'source tree' - and generating the requisite
Makefile.PL files.
I have some information at:

	http://www.wetware.com/drieux/CS/lang/Perl/PM/

The Good Enough Case Study is at:

	http://www.wetware.com/drieux/CS/Proj/PID/

This way one starts out from a safe beginning and does not
have to concern one's self with the vagaries of how both
the Vendor Did things with 'where is site_perl' as well
as how the FreakingPerlFascistSystemAdmin[1] did things:
eg:

[jeeves: 6:] rlogin vladimir
Last login: Sat Mar  8 12:55:33 from jeeves
Sun Microsystems Inc.   SunOS 5.9   Generic May 2002
vladimir: 52:] perl -MConfig -e 'print site lib:  
$Config{installsitelib} \nVendor Lib: $Config{installvendorlib}\n'
site lib:  /usr/local/lib/perl5/site_perl/5.6.1
Vendor Lib: /usr/local/lib/perl5/vendor_perl/5.6.1
vladimir: 53:] rlogin xlotl
Last login: Tue Feb 25 15:57:11 from jeeves
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California.  All rights 
reserved.

FreeBSD 4.6-RELEASE (GENERIC) #0: Tue Jun 11 06:14:12 GMT 2002

Welcome to FreeBSD!
xlotl: 52:]  perl -MConfig -e 'print site lib:  
$Config{installsitelib} \nVendor Lib: $Config{installvendorlib}\n'
site lib:  /usr/local/lib/perl5/site_perl/5.6.1
Vendor Lib:
xlotl: 53:] rlogin xanana
Last login: Sat Mar  8 11:10:12 from jeeves
xanana: 52:] uname -a
Linux xanana 2.4.18-10smp #1 SMP Wed Aug 7 11:17:48 EDT 2002 i686 
unknown
xanana: 53:] perl -MConfig -e 'print site lib:  
$Config{installsitelib} \nVendor Lib: $Config{installvendorlib}\n'
site lib:  /usr/lib/perl5/site_perl/5.6.1
Vendor Lib: /usr/lib/perl5/vendor_perl/5.6.1
xanana: 54:]

Since you leave those niggling details to be worked out when
the installer types
perl Makefile.PL
make test
make install
And IF you opt to pull your POD out of the Baz.pm into Baz.pod
then it will get parked appropriately as well Since of course
there is nothing more important than being able to go
	perldoc Foo::Bar::Baz

and there in the synopsis section you have all the cut and
paste solutions to simplify the process of generating the
code that will use your Foo::Bar::Baz module...
Then assuming that you shift into creating perl modules which
actually do have architecturally dependent components you will
again not have to worry about that part...
And at that point you will also have found a seamless way
to park all of this in which ever source code control system
you find useful. In Apple you should be very familiar with CVS,
old sun freaks like SCCS, die hard BSD heads are still soldiering
on with RCS, others come up with compromises such as perforce and ...
This way as bug reports come in from the field, you can keep
upgrading the product appropriately and re-distributing the tarball
ciao
drieux
---

[1] technically I am the site's FreakingPerlFascistSystemAdmin
but I have to do it in a way that conforms to the Proprieter's
penchance for deeply unresolved issues about BSD v. SYS V stuff
that goes back to system 7 issues  But we think that the
medication is starting to help some
8-)





Re: Where is site_perl?

2003-03-10 Thread Ken Williams
On Monday, March 10, 2003, at 10:44  AM, drieux wrote:
On Sunday, Mar 9, 2003, at 19:53 US/Pacific, Vicki Brown wrote:

OK, where is site_perl? ... or the moral equivalent thereof?
[jeeves: 94:] perl -MConfig -e 'print site lib:  
$Config{installsitelib} \nVendor Lib: $Config{installvendorlib}\n'
site lib:  /Library/Perl
Vendor Lib: /Network/Library/Perl
[jeeves: 95:]
By the way, an easy way to see config information is with the -V switch:

% perl -V:installsitelib -V:installvendorlib
installsitelib='/Library/Perl';
installvendorlib='';
(Hmm, looks like my installvendorlib isn't set properly!)

 -Ken



Re: Where is site_perl?

2003-03-10 Thread drieux
On Monday, Mar 10, 2003, at 09:21 US/Pacific, Ken Williams wrote:
[..]
perl -V:installsitelib -V:installvendorlib
first off thanks for the tip, somewhere I remember reading
that it should work that way, but I will confess a complete
blithe naivete about what I believe someone called 'perl golfing'
but clearly this is a most excellent trick worth having!
On a Default OSX box I note:

[jeeves: 96:] perl -V:installsitelib -V:installvendorlib
installsitelib='/Library/Perl';
installvendorlib='/Network/Library/Perl';
[jeeves: 97:] uname -a
Darwin jeeves.wetware.com 6.3 Darwin Kernel Version 6.3: Sat Dec 14 
03:11:25 PST 2002; root:xnu/xnu-344.23.obj~4/RELEASE_PPC  Power 
Macintosh powerpc
[jeeves: 98:]

In the for what it is worth catagory - I do not have
an actual /Network/Library/Perl directory on Jeeves,
so it is possible that while the default apple build
has the installvendorlib defined, they may not yet
have actually worked out what they are planning to do with it.
In much the same way that the solaris version of perl has
the installvendorlib defined, and the directory exists, but is empty.
{ eg:
vladimir: 65:] /usr/perl5/bin/perl -V:installsitelib -V:installvendorlib
installsitelib='/usr/perl5/site_perl/5.6.1';
installvendorlib='/usr/perl5/vendor_perl/5.6.1';
vladimir: 66:] perl -V:installsitelib -V:installvendorlib
installsitelib='/usr/local/lib/perl5/site_perl/5.6.1';
installvendorlib='/usr/local/lib/perl5/vendor_perl/5.6.1';
vladimir: 67:]
}
you might want to check if you have an 'open issue'
caused by installing one of the fink modules that
may bite you either that or you skipped a
step when building your version of perl.
IMMHO it is important to 'support' the installvendorlib for
those folks who would find it a useful way to
deliver vendor supplied, vendor supported perl modules.
ciao
drieux
---



Re: Where is site_perl?

2003-03-10 Thread Ken Williams
On Monday, March 10, 2003, at 12:18  PM, drieux wrote:
you might want to check if you have an 'open issue'
caused by installing one of the fink modules that
may bite you either that or you skipped a
step when building your version of perl.
Yeah, I'm sure that's what it's going to be - my perl is a fink package 
that I made myself, installing perl 5.6.1 as /sw/bin/perl and 
symlinking /usr/bin/perl to that.  I probably messed up the vendor libs 
in the process.

 -Ken



Re: Where is site_perl?

2003-03-10 Thread Vicki Brown
At 08:44 -0800 2003-03-10, drieux wrote:
At which point you may wish to correct the core defect here,
which is that your collection of 'perl modules' would be simpler
to manage had you started with say h2xs to simplify the process
of building out your 'source tree' - and generating the requisite
Makefile.PL files.


An excellent suggestion and many thanks for the references.

We will recommend this to the client, should he decide to go ahead and port
the suite to Mac OS X or BSD. :-)  His (current) packaging for Windoze is an
obfuscated compiled binary package containing all the necessary bits
including Perl itself... ala the Classic MacPerl runtime capability.
-- 
- Vicki

Vicki Brown ZZZ  Journeyman Sourceror:
P.O. Box 1269  zz  |\ _,,,---,,_Scripts  Philtres
San Bruno, CA   zz /,`.-'`'-.  ;-;;,_Perl, Unix, MacOS
94066 USA |,4-  ) )-,_. ,\ ( `'-'
mailto:[EMAIL PROTECTED]  '---''(_/--'  `-'\_)  http://www.cfcl.com/~vlb


Re: Where is site_perl?

2003-03-09 Thread Chris Devers
On Sun, 9 Mar 2003, Vicki Brown wrote:

 OK, where is site_perl? ... or the moral equivalent thereof?

For standard directories, /Library/Perl seems to be the moral equivalent
of /usr/local, but you have other options as well. I'm not sure how close
to standard my setup is, but:

% perl -e 'print join( \n,@INC)'
/sw/lib/perl5/darwin
/sw/lib/perl5
/sw/lib/perl5/darwin
/sw/lib/perl5
/System/Library/Perl/darwin
/System/Library/Perl
/Library/Perl/darwin
/Library/Perl
/Library/Perl
/Network/Library/Perl/darwin
/Network/Library/Perl
/Network/Library/Perl

% echo $PERL5LIB
/sw/lib/perl5:/sw/lib/perl5:/sw/lib/perl5

The latter environment variable, as declared in /sw/bin/init.{csh,sh}
(depending on if you kept tcsh or switched to bash), seems to be
responsible for adding the /se/lib lines to Perl's @INC library array.

If you wanted to add a custom library -- /usr/local say -- you could
probably do it by adding that directory to your ~/.*shrc (as appropriate)
file's PERL5LIB variable declaration. I'm just not sure if this is the
proper way to do it, but it seems like it should work.

In any case, you can probably use anything that shows up in your @INC
array. I'd tend to avoid /System/*, which Apple reserves the right to
clobber at your next system upgrade, and /sw/*, which is best left under
Fink's internal management. Since /Network is for shared stuff -- is
anyone using this that way, by the way? -- that pretty much herds you
towards using /Library/Perl, or a custom directory in $PERL5LIB.

Does that about cover it?



-- 
Chris Devers[EMAIL PROTECTED]

deconstructor, n. (C+-)
The special member function of a class X named ~~X.

Unlike the traditional C++ X::~X DESTRUCTOR, which destroys target
objects immediately, the C+- deconstructor first engages the memory
management system in a prolonged, acrimonious polemic, questioning the
naive assumption that OOP languages can model the real world.

-- from _The Computer Contradictionary_, Stan Kelly-Bootle, 1995