On Wed, Jun 25, 2008 at 12:07 PM, Andy Dougherty <[EMAIL PROTECTED]> wrote: > 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.
That sounds backward to me, and I'd recommend always honoring the command line. > 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". +1 > -- > Andy Dougherty [EMAIL PROTECTED] > -- Will "Coke" Coleda
