On Wed, 18 Jun 2008, [EMAIL PROTECTED] (via RT) wrote:

> # New Ticket Created by  [EMAIL PROTECTED] 
> # Please include the string:  [perl #56012]
> # in the subject line of all future correspondence about this issue. 
> # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=56012 >
> 
> 
> Hi,
> I have a bug using ccs make (/usr/ccs/bin/make). The following error 
> happens when I run make. 
> NOTE: /usr/xpg4/bin/make succeeds on the same host
> 
> $PATH = 
> /usr/openwin/bin:/opt/perl588/bin:/bin:/usr/bin:/opt/boksm/bin:/opt/perl588/site/git-1.5.5/bin:/opt/perl588/site/postgres/bin:/opt/SUNWspro/bin:/usr/ccs/bin
> uname -a == SunOS cmtnoc5-mx45 5.8 Generic_117350-38 sun4u sparc 
> SUNW,Sun-Fire-V490

[irrelevant lines deleted]

> mksh: Fatal error in reader: Loop detected when expanding macro value 
> `$(PERL) -e 'chdir shift @ARGV; system q{$(MAKE)}, @ARGV; exit $$? >> 8;''
> Current working directory /home/j911649/PARROT/solaris8

Odd.  I've built parrot numerous times with /usr/ccs/bin/make and have 
never seen this problem.  There's even specific code in _set_make_c in
config/inter/make.pm to avoid it:

    # RT#43171 this is an ugly hack
    # replace the value for $(MAKE) with the actual path or we'll end up
    # with a variable that recursively refers to itself
    $make_c =~ s/\$\(MAKE\)/$prog/;

    $conf->data->set( make_c => $make_c );

One way to reproduce this problem is to set an environment 
variable named 'MAKE' to point to a program that is not in your $PATH.
For example (this is /bin/sh syntax; I don't recall the csh equivalent)

        MAKE=/bin/bogus  perl Configure.pl

will give the result you see.  It's not at all clear to me what the author
of make.pm actually intended in such a case, so I'm hesitant to offer
a patch.  Normally, I'd say a workaround would be to explicitly supply
a --make=/usr/ccs/bin/make argument on the Configure.pl command line,
but make.pm deliberately chooses to prefer the environment to a command
line option.  Again, I don't know why, and it seems backwards to me,
but I'm reluctant to suggest changing it in case it was deliberate.

More generally, the default MAKE setting ought not to be recursive.  I
really don't know why that variable is called MAKE instead of something
like MAKE_C.  Using MAKE_C would eliminate the recursive issue without
the "ugly hack".

-- 
    Andy Dougherty              [EMAIL PROTECTED]

Reply via email to