Bug #327 for ExtUtils-MakeMaker: Special dmake/Win95 logic in subdirs() causing problems

Thu Mar 07 13:15:03 2002 Guest - Ticket created

Subject:

Strange subdir behavior in Windows platform

ExtUtils::MakeMaker 5.45 (Revision: 1.222) Perl Version: 5.6.1 MSWin32 (ActivePerl Build 631) In Windows platforms, the generated makefile (perl Makefile.PL) will contain an incorrect target when there are some subdirectories. Just do the following (don't even touch a line of code!): h2xs -A -X -n Anything (...) h2xs -A -X -n Anything::ThatOther (...) cd Anything perl Makefile.PL (...) make (...) ERROR: (the error message depends on the distribution and the make utitlity used). If you inspect the generated Makefile you will find (around line 380) a strange target like this: subdirs :: @[ <Tab> cd ThatOther <Tab> $(MAKE) all $(PASSTHRU) <Tab> cd .. ] As far as I know, this is not a valid Make sytax. The equivalent Makefile in a Linux box reads: subdirs :: <Tab> @cd ThatOther && $(MAKE) all $(PASTHRU)

Thu Mar 28 00:20:20 2002 mschwern [...] cpan.org - Status changed from 'new' to 'open'

Thu Mar 28 00:20:20 2002 mschwern [...] cpan.org - Correspondence added

Subject:

Special case dmake/Win95 logic in subdirs() may be bogus

[guest - Thu Mar 7 13:15:03 2002]: Show quoted text

> If you inspect the generated Makefile you will find (around line 380) > a strange target like this: > > subdirs :: > @[ > <Tab> cd ThatOther > <Tab> $(MAKE) all $(PASSTHRU) > <Tab> cd .. > ] > > As far as I know, this is not a valid Make sytax. The equivalent > Makefile in a Linux box reads: > > subdirs :: > <Tab> @cd ThatOther && $(MAKE) all $(PASTHRU)

Hmmm. There's special code in there for dmake on Win95 to generate exactly that. It determines which style to use based on what's in $Config{make} (ie. whatever make was used to build Perl). Lemme guess, you're using nmake? Try hand editing the Makefile so it has this: subdirs :: cd ThatOther $(MAKE) all $(PASTHRU) cd .. that should work, but it might be noisy. If so, try this: subdirs :: @ cd ThatOther @ $(MAKE) all $(PASTHRU) @ cd ..

Thu Mar 28 13:26:21 2002 mschwern [...] cpan.org - Status changed from 'open' to 'stalled'

Thu Mar 28 13:27:21 2002 mschwern [...] cpan.org - Subject changed from 'Strange subdir behavior in Windows platform' to 'Special dmake/Win95 logic in subdirs() causing problems'

Sat Aug 31 16:31:09 2002 The RT System itself - Status changed from 'stalled' to 'open'

Sat Aug 31 16:31:09 2002 kahn [...] cpan.org - Correspondence added

From:

kahn [...] cpan.org

I think I've found the patch for this problem. This patch avoids the @[] syntax when $NMAKE is set, which nmake doesn't like. Also see next post, which is a simplification of base class MM_Unix. [MSCHWERN - Thu Mar 28 00:20:20 2002]: Show quoted text

> [guest - Thu Mar 7 13:15:03 2002]:

> > If you inspect the generated Makefile you will find (around line

> 380)

> > a strange target like this: > > > > subdirs :: > > @[ > > <Tab> cd ThatOther > > <Tab> $(MAKE) all $(PASSTHRU) > > <Tab> cd .. > > ] > > > > As far as I know, this is not a valid Make sytax. The equivalent > > Makefile in a Linux box reads: > > > > subdirs :: > > <Tab> @cd ThatOther && $(MAKE) all $(PASTHRU)

> > Hmmm. There's special code in there for dmake on Win95 to generate > exactly that. It determines which style to use based on what's in > $Config{make} (ie. whatever make was used to build Perl). Lemme > guess, you're using nmake? > > Try hand editing the Makefile so it has this: > > subdirs :: > cd ThatOther > $(MAKE) all $(PASTHRU) > cd .. > > that should work, but it might be noisy. If so, try this: > > subdirs :: > @ cd ThatOther > @ $(MAKE) all $(PASTHRU) > @ cd ..

*** ExtUtils/MM_Win32.pm.backup Sat Aug 31 01:40:56 2002 --- ExtUtils/MM_Win32.pm Sat Aug 31 01:59:02 2002 *************** *** 79,84 **** --- 79,117 ---- } } # end of command.com workarounds + sub subdir_x { + my $self = shift; + my $subdir = shift; + if (Win32::IsWin95()) { + # Win-9x has nasty problem in command.com that can't cope with + # &&. Also, Dmake and Nmake disagree about how to make a + # commandseries silent: + if ($NMAKE) { + return <<EOT; + + subdirs :: + \@cd $subdir + \@\$(MAKE) all \$(PASTHRU) + \@cd .. + EOT + } + elsif ($DMAKE) { + return <<EOT; + + subdirs :: + @[ + cd $subdir + \$(MAKE) all \$(PASTHRU) + cd .. + ] + EOT + } + } + # if not windows 95, or not nmake/dmake, fall back to base + # implementation, which uses NOECHO and "&&" operator + return $self->ExtUtils::MM_Unix::subdir_x($subdir, @_); + } + sub dlsyms { my($self,%attribs) = @_;

Sat Aug 31 16:34:05 2002 kahn [...] cpan.org - Correspondence added

From:

kahn [...] cpan.org

Attached to this entry is a not-strictly-necessary simplification of the ExtUtils::MM_Unix module, removing the Windows-specific behavior that is never reached once you add the patch to MM_Win32 in the previous comment. --Jeremy [KAHN - Sat Aug 31 16:31:09 2002]: Show quoted text

> I think I've found the patch for this problem. This patch avoids the @[] > syntax when $NMAKE is set, which nmake doesn't like. Also see next post, > which is a simplification of base class MM_Unix. > > [MSCHWERN - Thu Mar 28 00:20:20 2002]: >

> > [guest - Thu Mar 7 13:15:03 2002]:

> > > If you inspect the generated Makefile you will find (around line

> > 380)

> > > a strange target like this: > > > > > > subdirs :: > > > @[ > > > <Tab> cd ThatOther > > > <Tab> $(MAKE) all $(PASSTHRU) > > > <Tab> cd .. > > > ] > > > > > > As far as I know, this is not a valid Make sytax. The equivalent > > > Makefile in a Linux box reads: > > > > > > subdirs :: > > > <Tab> @cd ThatOther && $(MAKE) all $(PASTHRU)

> > > > Hmmm. There's special code in there for dmake on Win95 to generate > > exactly that. It determines which style to use based on what's in > > $Config{make} (ie. whatever make was used to build Perl). Lemme > > guess, you're using nmake? > > > > Try hand editing the Makefile so it has this: > > > > subdirs :: > > cd ThatOther > > $(MAKE) all $(PASTHRU) > > cd .. > > > > that should work, but it might be noisy. If so, try this: > > > > subdirs :: > > @ cd ThatOther > > @ $(MAKE) all $(PASTHRU) > > @ cd ..

> >

*** ExtUtils/MM_Unix.pm.backup Sat Aug 31 01:31:06 2002 --- ExtUtils/MM_Unix.pm Sat Aug 31 01:55:42 2002 *************** *** 3315,3339 **** sub subdir_x { my($self, $subdir) = @_; my(@m); ! if ($Is_Win32 && Win32::IsWin95()) { ! # XXX: dmake-specific, like rest of Win95 port ! return <<EOT; ! subdirs :: ! @[ ! cd $subdir ! \$(MAKE) all \$(PASTHRU) ! cd .. ! ] ! EOT ! } ! else { ! return <<EOT; subdirs :: $self->{NOECHO}cd $subdir && \$(MAKE) all \$(PASTHRU) EOT - } } =item subdirs (o) --- 3315,3326 ---- sub subdir_x { my($self, $subdir) = @_; my(@m); ! return <<EOT; subdirs :: $self->{NOECHO}cd $subdir && \$(MAKE) all \$(PASTHRU) EOT } =item subdirs (o)

Sun Sep 01 20:16:15 2002 kahn [...] cpan.org - Requestor KAHN added

Wed Nov 13 20:00:22 2002 mschwern [...] cpan.org - Correspondence added

The basic dmake vs nmake syntax problem was fixed in another patch, but I applied your cleanup to move the Windows specific code out of MM_Unix. There is now an MM_Win95 and I put the subdir_x override there. I also made only dmake the special case. ie. instead of: if( $DMAKE ) { ...dmake code... } elsif( $NMAKE ) { ...nmake code.... } which causes a problem if someone uses something other than nmake or dmake. Since the nmake code is pretty normal make code, its just the default. Instead of the choice being dmake or nmake its now dmake or not dmake. Snapshot is available on makemaker.org. It will be in 6.06.

Wed Nov 13 20:00:23 2002 mschwern [...] cpan.org - Status changed from 'open' to 'resolved'