The Makefile syntax error that dmake reported is now resolved in svn by rev. 1477980.
The build process is now able to start, but you'll immediately find that it doesn't work for other reasons: ap_config_auto.h, included by ap_config.h, is missing. This doesn't happen when building with VC++/nmake because ap_config.h actually says this:
#if (!defined(WIN32) && !defined(NETWARE)) || defined(__MINGW32__)
#include "ap_config_auto.h"
...
i.e. ap_config_auto.h isn't normally included on Windows, but it is when using MinGW/dmake...
And therein lies the real problem: In order to build mod_perl using MinGW/dmake you must either
(1) use an Apache which was built with MinGW, or
(2) indulge in some manual intervention to allow building a MinGW mod_perl (or at least a mod_perl for use with a MinGW perl, like Strawberry Perl) with a VC++ Apache.
Option (1) is theoretically possible: According to
http://httpd.apache.org/docs/2.2/platform/win_compiling.html, "Only the Microsoft compiler tool chain is actively supported by the active httpd contributors. Although the project regularly accepts patches to ensure MinGW and other alternative builds work and improve upon them, they are not actively maintained and are often broken in the course of normal development."
I've personally never tried building Apache with MinGW, but the Changes file entries for 2.2.18 mention MinGW build improvements having been committed, so that version at least could well work. (I believe you would need an MSYS environment rather than just MinGW tools in a standard cmd.exe shell.)
Option (2) has apparently been explored by the maintainers of Strawberry Perl itself (as Mike has already said), and I've done the same myself and uploaded binaries here:
http://people.apache.org/~stevehay/
(Just a minor detail, as an aside: Note that the problem here is in using MinGW/gcc, not in using dmake. It is possible (although unusual) to build perl using VC++ with dmake. If you do that then mod_perl will also try to use the VC++/dmake combination and (as of the svn revision cited above) that works fine.)
I'm going to mark this ticket as 'Rejected' because given the rarity of building Apache with MinGW it is not realistic to add MinGW support to mod_perl. (And the manual intervention approach taken by both kmx and myself in pursuing option (2) above actually involved building mod_perl with ***VC++***, but in such a way that it works with a MinGW perl, so even that cannot be fitted into the mod_perl build process to assist people trying to use MinGW.)