(Apologies for the top-posted reply. Outlook Web Access isn't great...)

Should be fixed now in b14c7f9. There was already code in pod/buildtoc to edit 
the 'clean' section of the makefiles, but what it was looking for had parted 
company with what was in the makefiles.

Adding an easy-to-search-for macro defining the perldelta filename is a better 
idea, of course, to avoid similar breakage in the future, but this was easier 
for now. I might come back to this.


-----Original Message-----
From: Nicholas Clark on behalf of Nicholas Clark
Sent: Thu 07/10/2010 10:38
To: Steve Hay
Cc: [email protected]; [email protected]
Subject: Re: Smoke [5.13.5] v5.13.5-311-g6709de8 FAIL(F) MSWin32 WinXP/.Net SP3 
(x86/2 cpu)
 
On Thu, Oct 07, 2010 at 10:31:19AM +0100, Steve Hay wrote:
> Steve Hay wrote on 2010-10-07:
> > Automated smoke report for 5.13.5 patch
> > 6709de8803f0c22efc6a56325285452eb6dbb1e1 v5.13.5-311-g6709de8
> > maldoror.bath.planit.group: Intel(R) Core(TM)2 CPU 6700 @
> 2.66GHz(~2660
> > MHz) (x86/2 cpu)
> >     on        MSWin32 - WinXP/.Net SP3
> >     using     cl version 13.10.3077
> >     smoketime 6 hours 40 minutes (average 40 minutes 2 seconds)
> > 
> > Summary: FAIL(F)
> [...] 
> > ../t/porting/manifest.t.....................................FAILED
> >     7992
> >     ../t/porting/podcheck.t.....................................FAILED
> >     Non-zero exit status: 2 Bad plan.  You planned 598 tests but ran
> 425.
> > 
> 
> 
> These tests were failing on all but the first configuration because the
> Win32 makefile was deleting perl5135delta.pod instead of
> perl5136delta.pod when doing a 'make clean', hopefully now fixed by
> 579de39.
> 
> Not sure if other OSes have the same problem? Probably something in the
> release managers' guide needs updating too, or maybe a script somewhere
> needs fixing, or maybe I just cocked up 5.13.5 :-S

This should be scripted. It's a side effect of 37ee6528ceb851db.
The script that needs updating is pod/buildtoc

> I'll have a look later unless someone beats me to it.

It's probably best if you do, as you have access to win32 to test it.

Probably the best approach is to define a macro in the makefile for the
name of the current perldelta file (as that's easy for a script to locate
and update) and use that macro in the rules where it's actually needed.

Nicholas Clark

Reply via email to