in reply to Re^4: Make program used by Perl in windows
in thread Make program used by Perl in windows

Perl on Windows is currently built using either dmake.exe or nmake.exe. There is no way to currently build Perl on Windows using a GNU make. Also, ExtUtils::MakeMaker likely does not really support outputting GNU makefiles on Windows.

Traditionally, Perl uses the same toolchain that it was built with for building its modules. I'm not sure why you would want to change that, because that toolchain is proven to work well. Most likely, changing the make utility involves patching ExtUtils::MakeMaker to properly recognize the new type of make tool and produce the appropriate output.

Replies are listed 'Best First'.
Re^6: Make program used by Perl in windows
by bojinlund (Monsignor) on May 01, 2012 at 16:21 UTC
    Traditionally, Perl uses the same toolchain that it was built with for building its modules.

    Is it just a tradition or is it more? Is it possible to use different make programs even for different Perl modules?

    I'm not sure why you would want to change that, because that toolchain is proven to work well.

    I am thinking of:

    • Difficult to find good documentation on Dmake
    • GNU Make is more known than Dmake. There is a bigger user community.
    • GNU Make has a bigger “maintenance” group, with more frequent releases.
    Most likely, changing the make utility involves patching ExtUtils::MakeMaker to properly recognize the new type of make tool and produce the appropriate output.

    Yes, I know. And ExtUtils::MakeMaker is also "doomed" by it's maintainer!

[reply]

      I don't see what current problems there are with dmake and nmake that would be fixed by a move to GNU make - both other utilities work to build Perl and build its modules, and Perl does not use a make tool for anything else. But as you already seem to have a pretty clear picture of the steps to take, feel free to add a submodule to ExtUtils::MakeMaker that outputs GNU make syntax under Windows. The module is only "doomed" in the sense that schwern has a talk on this out. So far, there has come no replacement for ExtUtils::MakeMaker that is much better if better at all for building and installing Perl modules.

[reply]

      Is it just a tradition or is it more?

      Tradition is more :)

      Targeting yet another variant of make seems like a spectacular waste of time :)

      I wouldn't target gnu make, i'd target its replacement, makepp - Compatible but reliable and improved replacement for make, Or I would target http://www.bakefile.org/, and you automagically support everything and then some (I know, wishful thinking again )

      Yes, I know. And ExtUtils::MakeMaker is also "doomed" by it's maintainer!

      Seems you've missed the problem behind the punchline, have you actually watched read the slideshow? Or at minimum The Plea? Schwerns point is, make is non-portable external tool, don't patch MakeMaker to work with another make or do something new, just extend Module::Build, switch your distributions to Module::Build

[reply]

        The thing is that Module::Build has failed in its 10 years of existence to take over from ExtUtils::MakeMaker. In my opinion quite rightfully so, as it is far easier to debug a Makefile using make -n than it is to debug various opaque layers of Module::Build to find out what goes wrong.

        In retrospect, it seems that Module::Build falls in the same category as ORMs - instead of "I don't know SQL, so I want to write database access as if it were Perl" it falls in the pit of "I don't know make so I want to write module installation/compilation as if they were Perl".

        I understand that extending ExtUtils::MakeMaker may be much hairier than extending Module::Build, but when it fails, the Makefile generated by EU:MM is far easier to debug and "fix" (by direct editing) than divining the error cause from the Module::Build modules and inventing a fix for them.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom