Bug #4545 for ExtUtils-MakeMaker: MakeMaker in Win32 makes bad Makefile if PREFIX not set

Tue Dec 02 17:15:30 2003 Guest - Ticket created

Subject:

MakeMaker in Win32 makes bad Makefile if PREFIX not set

This bug breaks the install of SpamAssassin under Windows unless there is an explicit PREFIX=something on the perl Makefile.PL command line. Using ActivePerl 5.6.1 and ActivePerl 5.8.1 under Windows XP both produce the same results. Perl is installed in C:\Perl directory. C:\Perl\bin is in the path. This works with MakeMaker 5.45, is broken in Makemaker 6.05 and in 6.21. I didn't test other versions. I used the Makefile.PL from the latest CVS version of SpamAssassin, available at http://www.spamassassin.org If run perl Makefile.PL without specifying PREFIX=something, the generated Makefile contains the following correct lines when using MakeMaker 5.45: PREFIX = C:\Perl PERLPREFIX = $(PREFIX) SITEPREFIX = $(PREFIX) But with MakeMaker 6.05 and with 6.21, it contains the following lines: PREFIX = $(SITEPREFIX) PERLPREFIX = C:\Perl SITEPREFIX = C:\Perl\site which breaks everything because $(SITEPREFIX) is not yet defined when it is used. Besides, that's the wrong default for PREFIX. According to the perldoc it is supposed to default to installprefix. If I run perl -V:installprefix I get C:\Perl I'm not in a position to determine if this is really the same as bug #3275, but the strange errors that result from PREFIX being set weird look similar and are misleading.

Tue Dec 02 23:15:09 2003 Guest - Correspondence added

From:

sidney [...] sidney.com

I was playing with Net::DNS and found that perl Makefile.PL without any PREFIX=something produces the same erroneous PREFIX=$(SITEPREFIX) line. So this should be pretty easy to reproduce. The effect on trying to make the resulting Makefile may vary, but the bug can be seen by looking for the PREFIX = line in the generated Makefile.

Wed Dec 03 02:46:24 2003 schwern [...] pobox.com - Correspondence added

Date:	Tue, 2 Dec 2003 23:46:16 -0800
From:	Michael G Schwern <schwern [...] pobox.com>
To:	Guest via RT <bug-ExtUtils-MakeMaker [...] rt.cpan.org>
CC:	"AdminCc of cpan Ticket #4545": ;
Subject:	Re: [cpan #4545] MakeMaker in Win32 makes bad Makefile if PREFIX not set
RT-Send-Cc:

On Tue, Dec 02, 2003 at 05:15:30PM -0500, Guest via RT wrote: Show quoted text

> If run perl Makefile.PL without specifying PREFIX=something, the generated Makefile contains the following correct lines when using MakeMaker 5.45: > > PREFIX = C:\Perl > PERLPREFIX = $(PREFIX) > SITEPREFIX = $(PREFIX) > > But with MakeMaker 6.05 and with 6.21, it contains the following lines: > > PREFIX = $(SITEPREFIX) > PERLPREFIX = C:\Perl > SITEPREFIX = C:\Perl\site > > which breaks everything because $(SITEPREFIX) is not yet defined when it is used.

That looks correct. make should be able to handle that. What make are you using? How does this break? Can you check that by throwing something like this into your Makefile.PL: sub postamble { return q{ print_prefix: @echo $(PREFIX) }; } And trying 'make print_prefix' Show quoted text

> Besides, that's the wrong default for PREFIX. According to the perldoc it is supposed to default to installprefix.

The meaning of PREFIX has changed a bit. Previously it was *both* installprefix and the user set prefix. This caused maintenance headaches. To simplify matters its now just the user set prefix. PERLPREFIX, SITEPREFIX and VENDORPREFIX represent installprefix, installsiteprefix and installvendorprefix. If the user sets no PREFIX it defaults to whatever makes sense according to INSTALLDIRS. -- Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern/ Home of da bomb

Wed Dec 03 12:42:02 2003 Guest - Correspondence added

From:

sidney [...] sidney.com

[schwern@pobox.com - Wed Dec 3 02:46:24 2003]: Ah, it didn't occur to me that make would work with what looked like the variable being used before it is initialized, so I thought that was the problem. Adding the printout shows that PREFIX is fine. Using nmake under Win32 SpamAssassin definitely doesn't make using MakeMaker 6.05 or later, but now I have to track down the real reason and modify this bug report or submit one to SpamAssassin depending on the cause. Sorry about the false report.

Wed Dec 03 13:22:32 2003 schwern [...] pobox.com - Correspondence added

Date:	Wed, 3 Dec 2003 10:22:26 -0800
From:	Michael G Schwern <schwern [...] pobox.com>
To:	Guest via RT <bug-ExtUtils-MakeMaker [...] rt.cpan.org>
CC:	"AdminCc of cpan Ticket #4545": ;
Subject:	Re: [cpan #4545] MakeMaker in Win32 makes bad Makefile if PREFIX not set
RT-Send-Cc:

On Wed, Dec 03, 2003 at 12:42:03PM -0500, Guest via RT wrote: Show quoted text

> Ah, it didn't occur to me that make would work with what looked like the > variable being used before it is initialized, so I thought that was the > problem. Adding the printout shows that PREFIX is fine. Using nmake > under Win32 SpamAssassin definitely doesn't make using MakeMaker 6.05 or > later, but now I have to track down the real reason and modify this bug > report or submit one to SpamAssassin depending on the cause. Sorry about > the false report.

SpamAssassin does some dirty things inside MakeMaker, so I suspect its something in its Makefile.PL hackery. So what exactly *is* the bug? -- Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern/ Nature is pissed. http://www.unamerican.com/

Wed Dec 03 14:59:59 2003 Guest - Correspondence added

From:

sidney [...] sidney.com

[schwern@pobox.com - Wed Dec 3 13:22:32 2003]: Show quoted text

> So what exactly *is* the bug?

Well, it really looks like it is, as you said, inside the SpamAssassin Makefile.PL hackery, which is off topic for a bug report here, but since you asked... Under Windows XP, with the current CVS version of SpamAssassin, using ActivePerl 5.6.1 with MakeMaker 6.05 or greater installed (it ships with 5.45), or using ActivePerl 5.8.1 with MakeMaker 6.05 0r 6.21, and using nmake: 1) I found that I have to do this after playing around with it to be sure to reproduce the bug: nmake realclean 2) Then perl Makefile.PL nmake produces a lot of errors, starting with C:\spamassassin>nmake Microsoft (R) Program Maintenance Utility Version 1.50 Copyright (c) Microsoft Corp 1988-94. All rights reserved. Bareword found where operator expected at -e line 1, near ") lib" (Missing operator before lib?) Backslash found where operator expected at -e line 1, near "lib\" Backslash found where operator expected at -e line 1, near "Mail\" Backslash found where operator expected at -e line 1, near "SpamAssassin\" Bareword found where operator expected at -e line 1, near "/Mail/SpamAssassin" (Missing operator before SpamAssassin?) Backslash found where operator expected at -e line 1, near "lib\" [...] Looking at the Makefile it all seems be related to the PM_FILTER variable, which in Makefile.PL is set with 'PM_FILTER' => '$(PREPROCESS) -Mconditional -Mvars -DVERSION="$(VERSION)" -DPREFIX="$(I_PREFIX)"', In the Makefile it is used in two places, both which produce errors the same way. The first one starts out like this: $(NOECHO) $(PERLRUN) -MExtUtils::Install -e "pm_to_blib({@ARGV}, '$(INST_LIB)\auto', '$(PM_FILTER)')" \ lib/Mail/SpamAssassin/Replier.pm blib\lib\Mail\SpamAssassin\Replier.pm \ If I change $(NOECHO) to $(ECHO) where PM_FILTER is used, I can see the messed up result that is causing the errors: C:\Perl\bin\perl.exe -MExtUtils::Install -e pm_to_blib({@ARGV}, 'blib\lib\auto', ' -Mconditional -Mvars -DVERSION=2.70 -DPREFIX="') lib/Mail/SpamAssassin/Replier.pm blib\lib\Mail\SpamAssassin\Replier.pm lib/Mail/SpamAssassin/NetSet.pm blib\ Notice the -DPREFIX=" instead of -DPREFIX="C:\Perl\Site" Ok, that's the bug but I don't have a clue about the cause. I am not an nmake or a perl expert.

Thu Dec 04 03:40:47 2003 Guest - Correspondence added

From:

sidney [...] sidney.com

I think I see the problem, but I don't understand how it works with GNU make running under Cygwin... This is how PM_FILTER is set in Makefile.PL 'PM_FILTER' => '$(PREPROCESS) -Mconditional -Mvars -DVERSION="$(VERSION)" -DPREFIX="$(I_PREFIX)"', In the generated Makefile, the first use of PM_FILTER is earlier than the definition of PREPROCESS and $(PMFILTER) seems not to expand properly. If I replace $(PREPROCESS) in the definition of PM_FILTER with the definition of PREPROCESS, it all seems to work ok. But this doesn't explain how it works fine under CygWin. Looking at MakeMaker 5.45 under Win32, I don't see any place in the generated Makefile where PM_FILTER is ever defined. How is it supposed to work if it is not defined in the Makefile?

Thu Dec 04 15:39:24 2003 Guest - Correspondence added

From:

sidney [...] sidney.com

I found the cause of the problem. You can see it if you create a makefile containing just the following: testtarg: @echo foo1 $(FOO1) foo1 FOO1 = "This is foo1 text" If you use GNU make testtarg it outputs foo1 This is foo1 text foo1 But if you use nmake testtarg under Windows you get foo1 foo1 In other words, nmake requires a variable to be set earlier in the makefile than the first target that refers to it, while GNU make seems to process the entire makefile first, defining the variables, then processes the targets. To maintain portability to nmake you can't use GNU make's ability to define variables after the target.

Thu Dec 04 16:44:51 2003 schwern [...] pobox.com - Correspondence added

Date:	Thu, 4 Dec 2003 13:44:44 -0800
From:	Michael G Schwern <schwern [...] pobox.com>
To:	Guest via RT <bug-ExtUtils-MakeMaker [...] rt.cpan.org>
CC:	"AdminCc of cpan Ticket #4545": ;
Subject:	Re: [cpan #4545] MakeMaker in Win32 makes bad Makefile if PREFIX not set
RT-Send-Cc:

On Wed, Dec 03, 2003 at 03:00:00PM -0500, Guest via RT wrote: Show quoted text

> Looking at the Makefile it all seems be related to the PM_FILTER > variable, which in Makefile.PL is set with > > 'PM_FILTER' => '$(PREPROCESS) -Mconditional -Mvars > -DVERSION="$(VERSION)" -DPREFIX="$(I_PREFIX)"', > > In the Makefile it is used in two places, both which produce errors the > same way. The first one starts out like this: > > $(NOECHO) $(PERLRUN) -MExtUtils::Install -e "pm_to_blib({@ARGV}, > '$(INST_LIB)\auto', '$(PM_FILTER)')" \ > lib/Mail/SpamAssassin/Replier.pm > blib\lib\Mail\SpamAssassin\Replier.pm \ > > > If I change $(NOECHO) to $(ECHO) where PM_FILTER is used, I can see the > messed up result that is causing the errors: > > C:\Perl\bin\perl.exe -MExtUtils::Install -e pm_to_blib({@ARGV}, > 'blib\lib\auto', ' -Mconditional -Mvars -DVERSION=2.70 -DPREFIX="') > lib/Mail/SpamAssassin/Replier.pm blib\lib\Mail\SpamAssassin\Replier.pm > lib/Mail/SpamAssassin/NetSet.pm blib\ > > Notice the -DPREFIX=" instead of -DPREFIX="C:\Perl\Site"

Hmm. That shouldn't happen. Something's gone wrong with the quoting rules. The double quotes before pm_to_blib and the trailing one disappeared along with the value of $(I_PREFIX). Could you show me what I_PREFIX is set to the in Makefile? -- Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern/ I need a SHOWER a BURGER and some ROBOTS, STAT! -- http://www.angryflower.com/allrigh.gif

Thu Dec 04 16:54:15 2003 Guest - Correspondence added

From:

sidney [...] sidney.com

[schwern@pobox.com - Thu Dec 4 16:44:51 2003]: Show quoted text

> Could you show > me what I_PREFIX is set to the in Makefile?

That seems to be it... Both PREPROCESS and I_PREFIX are set in code that is generated by postamble, and so comes after the pm_to_blib section where PM_FILTER is first used. That is fine in GNU make, but with nmake it results in PREPROCESS and I_PREFIX both being empty when PM_FILTER is expanded. I moved the PREPROCESS and I_PREFIX definitions into the constants section and it worked fine.

Thu Dec 04 17:03:01 2003 schwern [...] pobox.com - Correspondence added

Date:	Thu, 4 Dec 2003 14:02:21 -0800
From:	Michael G Schwern <schwern [...] pobox.com>
To:	Guest via RT <bug-ExtUtils-MakeMaker [...] rt.cpan.org>
CC:	"AdminCc of cpan Ticket #4545": ;
Subject:	Re: [cpan #4545] MakeMaker in Win32 makes bad Makefile if PREFIX not set
RT-Send-Cc:

On Thu, Dec 04, 2003 at 03:40:47AM -0500, Guest via RT wrote: Show quoted text

> Looking at MakeMaker 5.45 under Win32, I don't see any place in the > generated Makefile where PM_FILTER is ever defined. How is it supposed > to work if it is not defined in the Makefile?

If the Makefile.PL doesn't define a PM_FILTER there won't be one. An undefined make variable simply defaults to an empty string. Anyhow, the SA Makefile.PL says this: # MakeMaker prior to 5.46 doesn't support PM_FILTER, so we have to # implement it ourselves. Also bear in mind that MakeMaker (5.45) from # Perl 5.6.1 supports that option while the one from 5.6.0 doesn't; they # do have the same version though! See bug 1652. $mm_has_pm_filter = $mm_version > 5.45 || ($mm_version == 5.45 && $] > 5.006 ); So if you're using Perl 5.6.0 it doesn't have PM_FILTER and SA works around it. -- Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern/ michael schwern is not

Thu Dec 04 17:34:16 2003 schwern [...] pobox.com - Correspondence added

Date:	Thu, 4 Dec 2003 14:34:08 -0800
From:	Michael G Schwern <schwern [...] pobox.com>
To:	Guest via RT <bug-ExtUtils-MakeMaker [...] rt.cpan.org>
CC:	"AdminCc of cpan Ticket #4545": ;
Subject:	Re: [cpan #4545] MakeMaker in Win32 makes bad Makefile if PREFIX not set
RT-Send-Cc:

On Thu, Dec 04, 2003 at 03:39:25PM -0500, Guest via RT wrote: Show quoted text

> In other words, nmake requires a variable to be set earlier in the > makefile than the first target that refers to it, while GNU make seems > to process the entire makefile first, defining the variables, then > processes the targets. To maintain portability to nmake you can't use > GNU make's ability to define variables after the target.

<grumble> Bloody one pass make implementations. </grumble> -- Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern/ <mendel> ScHWeRnsChweRN sChWErN SchweRN SCHWErNSChwERnsCHwERN sChWErn ScHWeRn schweRn sCHWErN schWeRn scHWeRN SchWeRN scHWErn SchwErn scHWErn ScHweRN sChwern scHWerN scHWeRn scHWerN ScHwerN SChWeRN scHWeRn SchwERNschwERn SCHwern sCHWErN SCHWErN sChWeRn

Thu Dec 04 17:44:02 2003 Guest - Correspondence added

From:

sidney [...] sidney.com

[schwern@pobox.com - Thu Dec 4 17:03:01 2003]: Show quoted text

> # MakeMaker prior to 5.46 doesn't support PM_FILTER, so we have to > # implement it ourselves.

I see what's going on. That was taken out of the CVS version about two months ago. There is no longer support for versions that don't have PM_FILTER. Show quoted text

> Also bear in mind that MakeMaker (5.45) from > # Perl 5.6.1 supports that option while the one from 5.6.0 doesn't

It's worse than that. I was trying to test using ActivePerl 5.6.1 (under Windows), which ships with MakeMaker 5.45. Looking at the MakeMaker code, the generation of the definition of PM_FILTER is in the constants sub in MM_Unix.pm, but is not in the constants sub (or anywhere else) in MM_Win32.pm. That is consistent with what I am seeing, that PM_FILTER is not defined in ActivePerl 5.6.1 with MakeMaker 5.45. Show quoted text

> $mm_has_pm_filter = $mm_version > 5.45 || ($mm_version == 5.45 && > $] > 5.006 > );

That explains why the above code did not work in (Windows) ActivePerl 5.6.1. But in any case the code no longer exists, leaving ActivePerl 5.6.1 still not working without an upgrade to a MakeMaker version with PM_FILTER. I think all the problems I was wrestling with are now identified: MakeMaker 5.45 doesn't have PM_FILTER in the Windows version, and Makefile.PL in SpamAssassin defines PREPROCESS and I_PREFIX too early for nmake but not a problem for GNU make.

Sat Dec 18 20:02:43 2004 mschwern [...] cpan.org - Correspondence added

[guest - Thu Dec 4 17:44:02 2003]: Show quoted text

> I think all the problems I was wrestling with are now identified: > MakeMaker 5.45 doesn't have PM_FILTER in the Windows version, and > Makefile.PL in SpamAssassin defines PREPROCESS and I_PREFIX too early > for nmake but not a problem for GNU make.

It looks like PREPROCESS and I_PREFIX are still getting set too late. I'm going to correct this by setting PM_FILTER as late as possible, at the end of the tools_other section.

Sat Dec 18 20:04:34 2004 mschwern [...] cpan.org - Correspondence added

[MSCHWERN - Sat Dec 18 20:02:43 2004]: Show quoted text

> [guest - Thu Dec 4 17:44:02 2003]:

> > I think all the problems I was wrestling with are now identified: > > MakeMaker 5.45 doesn't have PM_FILTER in the Windows version, and > > Makefile.PL in SpamAssassin defines PREPROCESS and I_PREFIX too early > > for nmake but not a problem for GNU make.

> > It looks like PREPROCESS and I_PREFIX are still getting set too late. > > I'm going to correct this by setting PM_FILTER as late as possible, > at the end of the tools_other section.

PS Try out the latest snapshot available from makemaker.org and let me know. http://www.makemaker.org/

Sat Dec 18 21:01:44 2004 mschwern [...] cpan.org - Status changed from 'new' to 'stalled'

Mon Sep 11 16:28:14 2006 mschwern [...] cpan.org - Correspondence added

Are you still having this problem on recent MakeMakers? Specificly 6.30_04 which is the latest alpha.

Mon Sep 11 16:28:15 2006 The RT System itself - Status changed from 'stalled' to 'open'

Mon Sep 11 16:28:29 2006 mschwern [...] cpan.org - Status changed from 'open' to 'stalled'

Wed Aug 28 17:04:28 2013 BINGOS [...] cpan.org - Correspondence added 10 min

This ticket is 7 years old. Assuming that the issue has been resolved. Many thanks.

Wed Aug 28 17:04:28 2013 The RT System itself - Status changed from 'stalled' to 'open'

Wed Aug 28 17:04:29 2013 BINGOS [...] cpan.org - Status changed from 'open' to 'resolved'