Re: ExtUtils::MakeMaker wrongly sets MAKE

  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