Best way, is by example:
Make a file called TEST_GIZMO.pm and stick this code into it:

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

use TEST_GIZMO;

test1;
test2;
TEST_GIZMO::test1; #this is "fully qualified name", a way to
                   #invoke test1 even if that name wasn't 
                   #explicitly exported.
[download]

I hope that this is enough "boiler plate" for you to create your own library functions. There is of course a lot to this subject, but I hope I got you started!

Thank you very much... It is working. But, should the script name (TEST_GIZMO.pm) and package name (TEST_GIZMO) be same?
Regards,
Anbarasu

Glad to hear that you got test code working. You are now well on your way!

Yes, putting package TEST_GIZMO inside of file TEST_GIZMO.pm would be the normal way. It is possible to have multiple packages within one file. The package is a name space. For what you are doing, that isn't necessary and can get confusing.

I would recommend that you put some sort of test function within the package. In one of my libraries, I just put sub test{} in every .pm file and of course didn't export the name "test" as every module has a test sub and the names would conflict. Then to test my library, I just call with the fully qualified name TEST_GIZMO::test; ModuleB::test;, etc. on all the .pm files. It is really handy to have the name of the file the same as package inside.

You will see that the .pm file can be run just like a .pl file. So you can have some sort of thing like "test if DEBUG"; DEBUG is a const flag. Anyway the idea is to get the package working with its own test routine before you start calling it from other programs.

You should consider your naming convention for your packages. You don't want to use names that might conflict with CPAN packages, etc. Say you've got some project TLA, then you could use TLA_Parse for say the parsing routines for project TLA. You'll have to decide what makes sense for whatever it is that you are doing.

As noted in perldoc perlmod, Perl code using the .pm file-extension can be placed into “packages” that can then be incorporated into other programs by means of the use and/or the require directives.

Perl locates these modules by iterating through the special array, @INC, which can be influenced in a number of ways:

1. The use lib directive.
2. The PERL5LIB or PERLLIB environment variables.
3. A built-in list whose contents are established when the Perl executable is first compiled.
4. Manual manipulation of the list in the usual way ... it is just an ordinary list variable.

“I intend this to be only a superficial glossing-over of the very substantial information to be found in perldoc perlmod, and is to this resource that I now direct your attention ...” he concluded, with a pointed and obviously-meaningful stare.