On 2010.8.14 4:18 PM, Daniel Pfeiffer wrote:
> From your doc:
> MAKE ... Defaults to $Config{make}.
>
> It should default to not being changed, so as to allow the user to
> choose which make he wants to use. Essentially you preclude Perl's own
> makepp.sourceforge.net from building subdirectories configured by
> MakeMaker :-(
makepp?! Well look at that, its being worked on again. Neat!
So there is a chicken/egg problem. At the point Makefile.PL is run it cannot
know what make you are going to use to run the generated Makefile. It has to
make a guess, and $Config{make} is all it has to go on. This is mostly
important to Windows users where dmake and nmake have very different and
incompatible syntaxes for fundamental things, like escape sequences.
If you're running with something other than $Config{make} you really should
let MakeMaker know by passing in MAKE. It *probably* doesn't matter for
anything but Windows, but I've seen makes do some stupid things.
As for MakeMaker not setting MAKE at all, its not guaranteed that a given make
variant will set MAKE. Setting MAKE was put in specifically for MMS (a
popular commercial VMS make variant) but I didn't check other variants. See
commit 04be35b73f4eb51d651980e0185b14ff0a87b847 back in 2004.
It may be possible to make that smarter, only set it if necessary, but you'd
need a way to detect that. If you can do some research to show that most
makes set MAKE then it can be made VMS-only code.
> You do have the undocumented feature of taking MAKE from the
> environment, if present.
This is documented in ExtUtils::MakeMaker cleverly hidden in the section
entitled "MAKE".
MAKE
Variant of make you intend to run the generated Makefile with. This
parameter lets Makefile.PL know what make quirks to account for when
generating the Makefile.
MakeMaker also honors the MAKE environment variable. This parameter
takes precedent.
> This is however not a solution, because
> (recursive make being an inherently faulty paradigm, search on the web
> for "recursive make considered harmful") makepp has some magic in
> $(MAKE) to feed the targets back to the main process, which has the
> complete view of dependencies. (This is a workaround for legacy builds,
> if you write makefiles for makepp, they can be much simpler and cleaner.)
Well, MakeMaker is considered harmful. :) I'm sorry to say that the boat has
loooong sailed on that one. The way MakeMaker handles recursive builds is
unlikely to change due to remaining compatible with existing extensions.
In the end, does "perl Makefile.PL MAKE=makep" work?
PS Tim, Andy and Andreas don't much work on MakeMaker anymore. Direct
discussion to makemaker@perl.org
--
52. Not allowed to yell "Take that Cobra" at the rifle range.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
