This continues an informal account of what I have done to have full access to CPAN modules under ActiveState's Perl for Win32 distribution (binary build package). Part 1 was published to my Journal previously.
In the first installment I mentioned that `make' plays a crucial role in the building of Perl modules from CPAN source tarballs. I have a personal aversion to the approach to installation of software on my system that regards the installation infrastructure (a.k.a. build apparatus) as a "black box" that I am foolish to want to open or know about. Some Perlers seem to regard module installation this way, but I do not. If the reader is one of those people who finds it religiously necessary to view the module installation process as "need to know only", or cannot grok just examining a thing simply out of a desire to understand how it works, I suggest that reader stop now and go find something else to do.
Since `make' is integral to the build-install process (it is assumed all readers know the canonical Perl installation quatrain and I won't cite it here) with any module employing the traditional MakeMaker utility system, I expect it to understand (parse and successfully execute) the Makefile that MakeMaker generates; but I also expect that sometimes it won't "just work." In the cases where it doesn't, I want to be able to fix the problem myself. I develop in C as well as in perl, and I build packages created by other developers in C; so I use the `make' tool in those other contexts as well. I see no sense or reason why I must submit to being force to use a different `make' tool for building Perl modules than the one I use ordinarily for general compilation tasks. In particular, the notion of using the `nmake' tool from MS is noxious and backwards to me. I will not do it.
Both the BSD make (a.k.a `pmake') and the GNU make (a.k.a. `gmake') are good, full-featured tools that are capable of managing highly complex systems of dependencies. So also is the `dmake' tool, which has suffered from not having very much documentation until rather recently. The OpenOffice.org people are using dmake to build OpenOffice on Win32 systems and are maintaining the source and documentation for it now; it can be obtained from their anonymous CVS repository. The other `pmake', the pure perl implementation mentioned in the first installment, isn't being developed any further, but might still suit some needs of some users.
So I strongly prefer, in fact, demand, to be able to use the `make' I am used to, to do the job of building CPAN modules. GNU `make' fits the bill nicely for me, and of course Cygwin supplies it. If one does not want to use Cygwin for some reason, there is also a GNU `make' provided by MinGW. See the following note, however, for why you might not want to go this route.
Note: The MinGW make requires a little bit of further discussion. At the time of this writing the MinGW-supplied make is somewhat "deprecated" by being named mingw32-make.exe and is not up to the task of building Perl modules under ActivePerl without some help. The codebase for Cygwin's make and the MinGW make are different; mingw32-make.exe is probably based on the upstream (standard) GNU make source,I guess, whereas Cygwin changes theirs. There are issues with unpatched GNU make (at this time: 3.80) on Win32 which have yet to be worked out. These are mostly related to the handling of pathnames in the Win/DOS style.
I am working on the CVS development source for GNU make, as are other people, and maybe within the foreseeable future the note above will no longer apply.
I will be adding to this journal sequence at the earliest available opportunity.
A manpage for `dmake' is available online
