Hi Michael,
la 08/15/2010 05:50 AM Michael G Schwern skribis:
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!
It never stopped, but the project lead fell out and nobody has any rights
except single file check-in on sourceforge. Snapshots have now and then been
provided on CPAN. But now I'm doing quality checks (like this one) and little
compatibility fixes getting ready for a 2.0 release, after many years of
improvements.
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.
$Config{make} is what some far away distributor chose to build perl. It
doesn't say anything about my machine...
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.
Well, ifndef is a gmake speciality. And POSIX doesn't mention MAKE.
How about configure style testing, unless your variable already points you to
a make that you know needs the setting:
.PHONY: all
all:
echo $(MAKE) > result-file
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.
It does, I'm blind...
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.
The short story is that it's the root cause for the need to make clean. Rich
Stallman has been aware of this milestone essay for a long time. His answer
is that there is nothing in gmake that forces you to do recursive builds. But
nonetheless the doc is full of how to do it. And there is nothing on how to
avoid it, understandably, because it's rather hard and not at all comfortable,
unlike with makepp.
In the end, does "perl Makefile.PL MAKE=makepp" work?
Like I said, no. $(MAKE) contains some magic, which the user should not have
to worry about. Actually there are two differents kinds of magic, one to
bring the whole processing back into one instance of makepp, and, where it's
so screwed that that doesn't work, a different magic falls back to real
recursive processes, but still with makepp.
You could put in special handling for that one, to *not* copy it into the
makefile. But even if you had the special handling, MAKE is not typically
exported. I stumbled across this in Git, which has perl Makefile.PL in its
makefile, rather than have a user type it in. Nobody would want to patch that
when building with makepp!
coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer
--
lerne / learn / apprends / lär dig / ucz się Esperanto:
http://lernu.net / http://ikurso.net
