Re: ExtUtils::MakeMaker wrongly sets MAKE

  la 08/16/2010 12:28 AM Michael G Schwern skribis:
> On 2010.8.15 4:59 AM, Daniel Pfeiffer wrote:
>>> 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...
> There's nothing else to go on. :-/
>
> You could grovel through PATH for things that look like make, but what happens
> when you find more than one?  (I have at least two on my OS X machine).  And
> then there's things like the Solaris UCB bizarreness where they basically have
> two parallel tool chains (usually Sun's and GNU's).
Without knowing which one you're generating for, there's no point in making 
choices in the makefile.

> Reason #23098 why MakeMaker turns out to be a bad idea.
>
>
>>> 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.
> Can't use ifndef, its incompatible with other makes and we don't know what
> make we're generating the file for.  Chicken/egg.
>
>
>> 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
> Which make binary do you run that with?  Chicken/egg.
No worse than just writing out a guess...

>>> 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.
> Is this magic different from gmake's MAKE magic?  If so, you're likely to run
> into issues beyond MakeMaker.
It's partly in the return value of $(MAKE) plus an environment variable.

> MakeMaker can *probably* get away with only setting MAKE on VMS, but it would
> need to be tested.  If you do the cross platform testing (dmake, nmake, gmake,
> BSD make) I'll patch it in.
I have all kinds of Perls on many systems, but few makes.  I could check z/OS, 
AIX and HP/UX if they have make installed.

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