On Wednesday, Sep 18, 2002, at 05:12 US/Pacific, Cricker wrote:

> Thanks, but I thought that modules were for submitting to CPAN.

a reasonable approach, in the long run, since you will find it
easier to install for both yourself and everyone else, IF you
build them in a way that is CPAN 'ready' as it were.

> Don't I
> have to go through all the @ISA and Exporter:: stuff if I write a 
> module?

yes and no. If you want to remain in a strictly 'functionalist'
approach - then you CAN get into the %EXPORT_TAGS approach where
you allow groups of functions to be exported together - as is the
way with many perl modules from the CPAN. Alternatively you can
just make a 'utility class' with all methods and no embedded data
so that everything "hangs" off an 'object' like entity

        my $foo = new FOO::BAR ;
        my $hash_ref = $foo->get_hash_ref_oh_stuff(@list_shrugged);

which does not require the 'Exporter stuff'....

>  I would like to get away with something simpler.

well 'simpler is as simpler does'....

as it says, "my ongoing war with Perl Modules" is at:

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

and I offer a 'case study' on why I personally
perfer to follow the perl documentation and start
with h2xs - cf:

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

since you get the quick introduction into the Maker
utilities and the standard approach that will allow
you to the standard

        perl Makefile.pl
        make
        make test
        make install

Since at some point in the process you will want to
actually 'install the module' so that it can be
used - and that means one of three strategies

        a) let perl put it in the site_perl on the host

        b) have your own ~/lib/perl5 - and hence a simple
                modification to the above that defines all of that.
                this will require the usual

                        b1: use lib "$ENV{HOME}/lib/perl5"
                        b2: setting the PERL5LIB environmental variable

        c) The MacApp Approach - that you FOO.pm be in the
                same directory as the executable so that it will
                be found based upon perl having been built to check
                "." for the other modules in the @INC - but this means
                being IN that directory when you fire up your app

of the three, the first is the simplest.

Remember the moment that it makes sense to move into doing
'perl libraries' - it's time to just get at home with doing
them as Perl Modules - and take the extra time to do it right
the first time - so that you can maintain them over the course
of time...


ciao
drieux

---


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

Reply via email to