volks,

this is a working draft - that I hope will help me frame
a better way to discribe the problem.

Prefatory Note: my expectation is that we are working in
a 'site local' context - rather than the folks who should
be over reading the perl monks - because you wish to work
on core functionality the the Canonical Name Spaces. { sub_note,
this is for the 'all perl' side - we get to integrating non-perl another 
day. }

I think we have seen the usual starting point for why one
starts off towards either a 'perl library' and/or a perl module,
one had that coffee break moment that said:

        there has to be a simpler way to get this set of
        functions I have into other scripts that does not
        require me to cut and paste them.

So the simplest place to go is the

        put it in a file and source that file in with

        require $Fully_Qualified_path_to_file_with_extenstion;

the problem as most folks learn after a while is that this mean
having that 'string' hard coded all over the place. And there is
no easy way to 'install it' every place that it needs to be.

we now have a growing problem list of:

        a) effective sourcing of our library

        b) the 'install side problem' of making sure it will be
                in a 'common place' to match what gets hard coded
                into the 'scripts/apps/exe/WhatEverYouCallYourPerlCode'

As we also noticed - there is that 'name space issue' - how do
I prevent My Test.pm from being confused with everyone else's -
including the canonical one - so let us add in here

        c) Name Space Management - The Macro Level

        d) Name Space Management - The Micro Level
                { how to keep my do_foo() from being confused with your do_foo() }

Then there is the generalized problem of

        e) so how do I upgrade this module/library to version 0.02 and
                know that I have not broken anything so far....

        f) how about a little documentation about your module...

My 'preaching' the 'h2xs way' - rests on the fact that it will help
us work most of these issue... but it in itself does not 'solve' all
of them .... all the way down.

The Macro Level name space problem can be helped along by working the
deal that one has opted to do a reasonable module naming schema that
will not likely clash with others.

        Wetware::Foo
        dtkp::Foo

note: technically 'dtkp' does not conform - as it does not
start with a Capital Letter - and I use that 'non-conformance'
to cover things that are strictly 'demo ware'....
{ I have dips on DTK::* }

A safe rule of thumb is to use a unique name - such as the
corporation Stock Exchange Symbol - or at least the one you
guys hope to IPO on:

        WARP::*
        ENE::*

both were used - but were never 'open sourced'.... #include "eneRant.h"

so now when you type

        h2xs -AX WARP::joeBob

it will generate all of the files you expect. cf -

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

We of course all know that we will fill in the POD section -
so we have the start of the documentation process - and if we
'manify' - we can also get other documentation in play....

the first part of solving the:

        how to install properly
        how to reference properly

comes free of charge with the whole 'Makefile.PL' that it
generated - since on top of our standard

        perl Makefile.pl
        make
        make test
        make install

that some use to run the tests and install the code, there is
also the target

        make dist

that will generate up a 'distribution' tarball that others will
be able to access ... by webPage download, anon ftp, email attachment,
sneeker net...

where we start 'earning our pay' in the process is that the
same 'tarball' once it lands on the remote hosts will unwrap
and install as we expect. If you have root - or your sysFreaks
allow open installation into the 'shared space' where perl
modules go - then you would see something like:

darwin side:
[jeeves:perl/dtkp/WebMe] root# make install
Manifying blib/man3/dtkp::WebMe.3
Installing /Library/Perl/dtkp/WebMe.pm
Installing /usr/share/man/man3/dtkp::WebMe.3
Writing /Library/Perl/darwin/auto/dtkp/WebMe/.packlist
Appending installation info to /System/Library/Perl/darwin/perllocal.pod
[jeeves:perl/dtkp/WebMe] root#

solaris side:
vladimir: 54:] make install
Manifying blib/man3/dtkp::WebMe.3
Installing /usr/local/lib/perl5/site_perl/5.6.1/dtkp/WebMe.pm
Installing /usr/local/man/man3/dtkp::WebMe.3
Writing /usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris/auto/dtkp/WebMe/
..packlist
Appending installation info to 
/usr/local/lib/perl5/5.6.1/sun4-solaris/perllocal.pod
vladimir: 55:]
......<yourOSStyleHere>.....

Notice that now the same set of scripts that have the

        use dtkp::WebMe ;

will, gosh, work on both darwin and solaris - without having
to expressly call out where the 'WebMe.pm' has been installed.

In the case that you do not have root, and are doing a 'local install'
then the 'traditional trick' is to have a

        lib/perl

sub directory - since, you may also need to have

        lib/python
        lib/AngstFestivalDeJureDeManageMentLikes
        lib/ThatCoolNewLanguageThatWillRule
        .....

and it is at that part of the game where you do the 'funky trick'

        perl Makefile.PL PREFIX=$prefix LIB=$lib INSTALLMAN3DIR=$man

{ or you are seriously SICK and have all of that in an environmental
variable, or a script or a.... see appended at the end }

if you had to take this side adventure - then you already know to
work around it with

        use lib "$ENV{HOME}/lib/perl";
        use dtkp::WebMe ;

and you are out and away again.

This leaves us with the 'continual maintance problem' - which
means wrapping our head around

        perldoc Test
        perldoc Test::Harness

or "how to stuff that t/*.t stuff into play" since the default
behavior of your make file will be to check there and see if
you have ginned up any test harnesses...

cf:
http://www.wetware.com/drieux/CS/Proj/GlobalGame/

and now we find that our basic problem is left down to the
'micro name space issues' - as well as - so How Do i stuff
that stuff into the section between the

        our $VERSION = '0.01';
        
        # Preloaded methods go here.

        1;

Religiously you should put them between the 'preload' line
and the "1;" - since that is what it says - or you should
cut and past your stack of functions in at that line....
{ the "1;" lets the 'use FOO::BAR' know that it has reached
a happy space.... }



ciao
drieux

---

#!/usr/bin/perl -w
use strict;

my $prefix = $ENV{HOME};
my $lib = "$prefix/lib/perl";
my $man = "$prefix/man";

my $cmd = "perl Makefile.PL PREFIX=$prefix LIB=$lib INSTALLMAN3DIR=$man";

system("make clean");


system($cmd);
system("make test");
system("make install");

#--------
this generates

[jeeves:~/perl/dtkp/WebMe] drieux% perl installMe
rm -rf ./blib Makefile.aperl blib/arch/auto/dtkp/WebMe/extralibs.all 
perlmain.c mon.out core core.*perl.*.? *perl.core so_locations pm_to_blib 
*~ */*~ */*/*~ *.o *.a perl.exe  WebMe.bso WebMe.def WebMe.exp
mv Makefile Makefile.old > /dev/null 2>&1
Checking if your kit is complete...
Looks good
Writing Makefile for dtkp::WebMe
mkdir blib
mkdir blib/lib
mkdir blib/lib/dtkp
mkdir blib/arch
mkdir blib/arch/auto
mkdir blib/arch/auto/dtkp
mkdir blib/arch/auto/dtkp/WebMe
mkdir blib/lib/auto
mkdir blib/lib/auto/dtkp
mkdir blib/lib/auto/dtkp/WebMe
mkdir blib/man3
cp WebMe.pm blib/lib/dtkp/WebMe.pm
PERL_DL_NONLAZY=1 /usr/local/bin/perl -Iblib/arch -Iblib/lib 
-I/System/Library/Perl/darwin -I/System/Library/Perl test.pl
1..1
ok 1
Manifying blib/man3/dtkp::WebMe.3
Installing /home/drieux/lib/perl/dtkp/WebMe.pm
Installing /home/drieux/man/dtkp::WebMe.3
Writing /home/drieux/lib/perl/darwin/auto/dtkp/WebMe/.packlist
Appending installation info to /home/drieux/lib/perl/darwin/perllocal.pod
[jeeves:~/perl/dtkp/WebMe] drieux%



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to