When going through the "make; make test; make install;" commands during normal module installation, there are various things that may or may not happen. Many modules are not pure perl, and have inline c functions or link to external functions/modules/code. During the make period, I believe that inline c compliation will happen, as well as checking that things that inline c touches (c headers) will be checked for their existence.

During "make test", the tests included with the module will be run, ensuring that interaction between the code in the module and the system modules/perl is acting as expected (in the eyes of the module writer). Without this step, there maybe unexpected results when running code using these modules.

make install simply moves the modules to the proper places on the system, which is what you are doing with your ftp'ing.

I'd suggest doing the full module installation procedure whenever possible. It may save you some headaches later on in debugging.

Also, always use SSH not Telnet. Telnet passes your info in plaintext (user/pass) and SSH is a fully secure connection.

Thanks hubb0r, that makes sense. I just don't understand why I get so many errors and failed installs.

Here's what Pair has me doing:

ssh myusername@servername.pair.com.

enter password

/usr/local/bin/perl -MCPAN -e shell

cpan> o conf makepl_arg LIB=/usr/home/myusername/modules
cpan> install CPAN::Modulename

[look for -- OK] (rare)
q
exit
[download]

Oh, and it looks like I'm using SSH.


—Brad
"The important work of moving the world forward does not wait to be done by perfect men." George Eliot

What kinds of errors/failed installations are you getting?

As hubb0r points out, the make steps will ensure that everything happens correctly. Mostly. For example, if there is any native (XS) code, it'll get compiled into appropriate libraries, etc.

That said, I've found two things that are key to making my life easier with non-standard install paths (aka private install paths): PREFIX and LIB, e.g., "perl Makefile.PL PREFIX=/srv/www/lib LIB=/srv/www/lib". I set them both to the same place, and then use lib "PREFIX/LIB setting" in my code, and everything is hunky-dory.

The advantages really are two-fold: one, if there is any XS code, you can be sure you're compiling correctly (if this fails, then you have some serious advanced issues to deal with - such as compiling on a machine other than the one you deploy on, which is something to be sure you know how to do before attempting it), and two, you can run the tests in the real production environment which helps ensure that your code will work, too - if you get errors during the make test phase, for example, you may be a little suspicious as to whether you have everything needed for that module to work. Or just running "perl Makefile.PL" - if that fails, it should tell you what other modules you're missing. I've found modules where "perl Makefile.PL" failed to tell me about a missing requirement, but running "make test" failed due to that missing requirement, then I went and installed that extra module, and all worked after that.

You can really save yourself a lot of hair pulling by doing things the "normal" way. If you don't, you need to be aware of the errors that you may encounter and what they mean - they aren't nearly as obvious later in production as they are during module deployment.