• Bad command or file name

You should investigate where these are coming from.

• Unable to find a perl 5 (by these names: C:\perl\bin\Perl.exe miniperl perl perl

This looks like the version of Perl you are using doesn't realize that '\\' is a path delimiter. If it did, it would strip the first part and be looking for "perl.exe" in your PATH. I suspect both of these problems stem from trying to combine Unixish tools and ActivePerl. A lot of work has gone into getting Perl to work under Win32 and a lot of work has gone into building Unixish things for Win32, including making those Unixish things able to build and use Perl in a Unixish manner. However, using ActivePerl in a Unixish environment for Win32, is going to generate a few problems.

• I used GNU Make since nmake didn't agree with the syntax of the makefile

This means that the version of Perl you are using has not been configured to be used with nmake.

Which brings us to the golden rule when installing modules:

• Build (and install) the module using the same tools you used to compile perl!

"Ah," you say, "but I didn't compile Perl."

Which lead to two question: "Why not?" and "Then what did whoever compiled it for you use?"

Those two questions lead to two solutions. First, you can go build Perl yourself and then installing modules works the way it was originally designed to.

Second, you can try to duplicate the environment that ActiveState (or whoever) used to compile your Perl so that installing modules will work.

Third (surprise!), you can try to hack the configuration files (which are set up automatically when you compile Perl) to match whatever environment you have lying around for building modules. This may or may not work. Support for this is slowly growing, especially for the case of using free tools to build/install modules for "ActivePerl".

I think if you look around you can find FAQs covering the last two choices. The first choice is covered in the instruction files that come with the Perl source code.