perltutorial
syphilis
First thing to do, of course, is to install 'dmake.exe' and the MinGW compiler. (Note that <code>nmake</code> can also be used instead of <code>dmake</code>. <a href="http://download.microsoft.com/download/vc15/patch/1.52/w95/en-us/nmake15.exe">Nmake15.exe</a> contains an older version of nmake that doesn't provide the milage that dmake delivers - though, depending upon what you build, you may never be bitten by this lack of milage. Recent versions of nmake are fine.)
<br><br>To install dmake and MinGW, simply run <c>ppm install MinGW</c><br><br><b>Note:</b> From here on, I'm assuming that dmake is being used. If you're using nmake, then it's just a matter of substituting "nmake" for "dmake" in the commands.
<br><br>So long as you're running build 815 (or later) of ActiveState Perl, that's theoretically (see the <b>Bugs and Their Fixes</b> section below) all you need to do.
Assuming that both MinGW and dmake are in your path, and that neither Microsoft's cl compiler nor nmake can be found in the path, then ActiveState Perl will automatically use dmake and MinGW, and the appropriate %Config values will be loaded. (If cl is in your path, and you want to use gcc, you must either remove cl from the path, or set the ACTIVEPERL_CONFIG_CC environment variable to gcc. If nmake is found in your path, then you can't use dmake - but nmake will work just as well with gcc as it does with cl. See <c>perldoc ActivePerl::Config</c> for details.)<br>
You can then build C/C++-based modules by simply downloading the source tarball from CPAN, extracting it to some location,
cd'ing to that location and running:
<code>
perl Makefile.PL
dmake test
dmake install
</code>
Or you can do it using the automation provided by CPAN.pm.
<br><br>For builds earlier than build 815 (including builds of perl 5.6), it is necessary to also install
<a href="http://search.cpan.org/~mbarbon/ExtUtils-FakeConfig-0.09/">ExtUtils::FakeConfig</a> in accordance
with the instructions found in its README.txt. (Note that one can also use ExtUtils::FakeConfig with builds 815 and later, if one wishes). That done, it's then just a matter of building modules by running:
<code>
perl -MConfig_m Makefile.PL
dmake test
dmake install
</code>
It's the '-MConfig_m' that loads EU::FC's Config_m.pm (and hence the appropriate %Config values). However, in the building of various perl modules
(eg PDL), the Makefile.PL may run 'perl -e' commands that need to be run
as 'perl -MConfig_m -e'. In order to ensure that EU::FC's Config_m.pm values are loaded <b>every</b>
time perl is run, we can just set the perl5opt environment variable to <code>-MConfig_m</code>:
<code>
set perl5opt=-MConfig_m
</code>
Having done that, we no longer need to specify the <code>-MConfig_m</code> option, so it's back to running:
<code>
perl Makefile.PL
dmake test
dmake install
</code>
<br><b>Bugs and Their Fixes</b><br><br>
I don't know of any bugs as regarding version 0.09 (or later) of ExtUtils::FakeConfig, so if you're using its <code>-MConfig_m</code> option to load the appropriate <code>%Config</code> values, then you can ignore what follows. However, if you're relying on the automation provided by ActiveState builds prior to build 821, then there are some areas
where ActiveState haven't quite got it right.<br><br> At time of original writing, build 820 was the latest ActivePerl build. I
know of only one problem with it. $Config{obj_ext} remains set to '.obj' (as can be seen by running
<code>perl -V:obj_ext</code>). But it needs to be set to
'.o'. To fix, open up perl/lib/Config.pm, locate the line <code>obj_ext => '.obj',</code> and remove it (or comment it out).
<br><br>IIRC, builds 815 to 819 insisted on setting $Config{ld} to 'gcc'. Running
<code>perl -V:ld</code> will reveal what $Config{ld} is set to. If it reports 'gcc', open up ActivePerl/Config.pm
which, with builds 815 to 818 is in perl/site/lib, but is in perl/lib with subsequent builds.
Find the line that specifies <code>_override("ld", "gcc");</code> and change the 'gcc' to 'g++'.<br><br>
While you've got that file open, check to see what <code>perl -V:lib_ext</code> reports. If it reports that
'lib_ext' is set to '.a', then all is well, but if it reports that 'lib_ext' is set to '.lib' then
add <code>_override("lib_ext", ".a");</code> to that same list of _override() calls. Also, in the
same file (near the top), find the lines:
<code>
ldflags
libc
libs
</code>
and change that to:
<code>
ldflags
libc
lib_ext
libs
</code>
And then, for that change to the $Config{lib_ext} setting to take effect, it is necessary to open perl/lib/Config.pm,
find the line <code>lib_ext => '.lib',</code> and either remove that line or comment it out. <br><br> These are the only such bugs I know of - though I've never used build 815 or 818. (Build 816 should be avoided at all costs - for unrelated reasons). <br><br>Cheers,<br>Rob<br>
<b>Updates:</b> Altered the advice on how to install dmake and MinGW on the basis of [jdporter]'s comments; <br>Amended "per5opt" to the correct "perl5opt" - thanks [Intrepid]<br>Build 822 of ActivePerl has since been released - no known problems wrt MinGW and dmake.<br>Changed (again) instructions on the installation of dmake and MinGW, as these can now be installed using ppm.<br>Corrected info given about how ActivePerl determines which compiler/make to use.