Getting MozillaBuild and CPAN talking again
The Mozilla Project has a history of producing useful software and tools in the pursuit of its main mission that are not directly in the path of its mission.
MozillaBuild is one of these.
If you’re trying to build something that’s in any way similar to or remotely expects a Unix-ishy environment, and you don’t want to deal with Cygwin’s eccentricities1, MozillaBuild not only provides such an environment, but packages a host of useful goodies along with it.
In short, MozillaBuild provides enough “It Just Works ™”-ed-ness for the whole family! It’s gotten to the point where I often forget that I actually still am in Windows when using it2.
Recently, though, a jarring reminder that I was, indeed, still in Win32-land occurred as I went to install some Perl3 modules a particular tool we use pretty heavily here at Songbird depended on.
I went to run the command on our Win32 release build machine, and was met with a missing-modules error. “No matter, that’s what CPAN’s for!” I say. Weeelll… not so fast.
It turns out MozillaBuild’s Perl installation didn’t get the memo that it’s in a Win32 environment, so when you try to run CPAN, you’ll get all sorts of errors.
Apparently, I’m not the only one to have had this problem.
Since I really needed to get this tool working on Win324, I did some couples counseling with MozillaBuild5 and CPAN, and came up with a fix:
- Configure CPAN.
- Log in as Administrator
- Run perl -MCPAN -e 'shell'.
- When prompted whether you’re “ready for manual configuration,” say “no”
- Exit the shell
- In an MSYS terminal, manually edit /usr/lib/perl5/5.6.1/CPAN/Config.pm; change the following variables:
- build_dir: [Anything that doesn't contain a space; I ended up using:] /d/.cpan/build
- cpan_home: /d/.cpan
- ftp: /bin/false
- keep_source_where: /d/.cpan/sources
- urllist: q[http://mirrors1.kernel.org/pub/CPAN], q[http://mirrors2.kernel.org/pub/CPAN], q[http://ftp.osuosl.org/pub/CPAN/]]
- Run perl -c on /usr/lib/perl5/5.6.1/CPAN/Config.pm to make sure it compiles and you didn't typo anything in the changes you
- Apply the following patch to /usr/lib/perl5/5.6.1/CPAN.pm.
And you're done!6
You should now be able to run commands like:
perl -MCPAN -e 'shell' install Digest::Perl::MD5 force install URI
One (rather large) caveat to this process is many Perl modules have C extensions that get built at installation time. Most of these assume Unix, and therefore that gcc is around.
If you don't have a full MSYS environment, installing them will fail, unless you can turn these bindings off. (Even in the case of some modules (URI, for instance), they will refuse to install because of failed tests; you can get around this by forcing an installation.)
It's not perfect, but if your requirement is pure Perl modules, as mine was, it's a workable solution.7
__________________________
1 And less-than-spectacular performance
2 as much as that's possible to do; I usually remember around the point I want to copy/paste some text around...
3 Yes, yes, I know; Python forever... but every build infrastructure I've ever worked with has perl in it... somewhere
4 Otherwise, our Lord and Savior, AUTOMATION, couldn't proceed
5 I experienced this issue with MozillaBuild 1.3, but I checked the latest MozillaBuild and the Perl installation there doesn't seem to have changed, so this process+patch should still be applicable
6 What this process is generally doing is: removing paths with spaces in them, since %20's in Unix paths are a rarity; skipping manual CPAN configuration which will get tripped up on a bunch of things and generally try to install the world for you; always cause ftp commands (which use ftp.exe) to fail, since ftp.exe != the venerable unix ftp, and the CPAN module will get very confused trying to talk to it; and finally, forcing CPAN to always use wget, which MozillaBuild includes, but not use redirection to save files, since MSYS seems to (unhelpfully, I might add) attempt to translate line endings for you.
7 Until you just rewrite your can't-live-without-it tool in Python...