Skip Menu |
Report information
Id: 133033
Status: open
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: sisyphus <sisyphus1 [at] optusnet.com.au>
Cc:
AdminCc:

Operating System: (no value)
PatchStatus: (no value)
Severity: low
Type: unknown
Perl Version: (no value)
Fixed In: (no value)



Subject: [Win32] t/porting/pod_rules.t fails test 3 if win32/GNUmakefile has been altered
To: <perlbug [...] perl.org>
From: <sisyphus1 [...] optusnet.com.au>
Date: Tue, 27 Mar 2018 23:49:27 +1100
Download (untitled) / with headers
text/plain 3.6k
Hi, If the win32/GNUmakefile has been altered in any way (even just converting line endings from 'unix' to 'dos') then, with latest devel perl (5.27.10) I get: C:\_32\comp\perl-5.27.10-mod>perl t/porting/pod_rules.t 1..8 ok 1 # got Pod metadata ok 2 # win32/makefile.mk is up to date not ok 3 # win32/GNUmakefile is up to date ok 4 # MANIFEST is up to date ok 5 # win32/Makefile is up to date ok 6 # win32/pod.mak is up to date ok 7 # Makefile.SH is up to date ok 8 # vms/descrip_mms.template is up to date Otherwise all tests pass. Given that editing (ie manually configuring) these Windows makefiles is deemed to be a valid practice, it must surely be a bug in pod_rules.t tests that such a practice causes a test to fail. I think this issue has been around for a while. I think it likely (untested) that the same test fails with win32/Makefile or win32/makefile.mk when they are in use (and have been altered). Cheers, Rob Summary of my perl5 (revision 5 version 27 subversion 10) configuration: Platform: osname=MSWin32 osvers=6.1.7601 archname=MSWin32-x86-multi-thread-64int uname='' config_args='undef' hint=recommended useposix=true d_sigaction=undef useithreads=define usemultiplicity=define use64bitint=define use64bitall=undef uselongdouble=undef usemymalloc=n default_inc_excludes_dot=define bincompat5005=undef Compiler: cc='gcc' ccflags =' -s -O2 -DWIN32 -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -D__USE_MINGW_ANSI_STDIO -fwrapv -fno-strict-aliasing -mms-bitfields' optimize='-s -O2' cppflags='-DWIN32' ccversion='' gccversion='7.2.0' gccosandvers='' intsize=4 longsize=4 ptrsize=4 doublesize=8 byteorder=12345678 doublekind=3 d_longlong=define longlongsize=8 d_longdbl=define longdblsize=12 longdblkind=3 ivtype='long long' ivsize=8 nvtype='double' nvsize=8 Off_t='long long' lseeksize=8 alignbytes=8 prototype=define Linker and Libraries: ld='g++' ldflags ='-s -L"C:\_32\blead-5.27.10-mod\lib\CORE" -L"C:\_32\gcc-mingw-720\mingw32\lib"' libpth=C:\_32\gcc-mingw-720\mingw32\lib C:\_32\gcc-mingw-720\mingw32\i686-w64-mingw32\lib C:\_32\msys_720\1.0\local\lib C:\_32\gcc-mingw-720\mingw32\lib\gcc\i686-w64-mingw32\7.2.0 libs= -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 -lquadmath perllibs= -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 -lquadmath libc= so=dll useshrplib=true libperl=libperl527.a gnulibc_version='' Dynamic Linking: dlsrc=dl_win32.xs dlext=dll d_dlsymun=undef ccdlflags=' ' cccdlflags=' ' lddlflags='-mdll -s -L"C:\_32\blead-5.27.10-mod\lib\CORE" -L"C:\_32\gcc-mingw-720\mingw32\lib"' Characteristics of this binary (from libperl): Compile-time options: HAS_TIMES HAVE_INTERP_INTERN MULTIPLICITY PERLIO_LAYERS PERL_COPY_ON_WRITE PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS PERL_MALLOC_WRAP PERL_OP_PARENT PERL_PRESERVE_IVUV USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_LOCALE_TIME USE_PERLIO USE_PERL_ATOF Built under MSWin32 Compiled at Mar 21 2018 18:53:01 @INC: C:/_32/comp/perl-5.27.10-mod/lib
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 2.5k
On Tue, 27 Mar 2018 05:49:54 -0700, sisyphus wrote: Show quoted text
> Hi, > > If the win32/GNUmakefile has been altered in any way (even just > converting > line endings from 'unix' to 'dos') then, with latest devel perl > (5.27.10) I > get: > > C:\_32\comp\perl-5.27.10-mod>perl t/porting/pod_rules.t > 1..8 > ok 1 # got Pod metadata > ok 2 # win32/makefile.mk is up to date > not ok 3 # win32/GNUmakefile is up to date > ok 4 # MANIFEST is up to date > ok 5 # win32/Makefile is up to date > ok 6 # win32/pod.mak is up to date > ok 7 # Makefile.SH is up to date > ok 8 # vms/descrip_mms.template is up to date > > Otherwise all tests pass. > Given that editing (ie manually configuring) these Windows makefiles > is > deemed to be a valid practice, it must surely be a bug in pod_rules.t > tests > that such a practice causes a test to fail. > I think this issue has been around for a while.
pod_rules.t complains only if the section of the file starting with: # Note that this next section is parsed (and regenerated) by pod/buildtoc # so please check that script before making structural changes here is modified, which changing line endings does. If I modify only CCTYPE and WIN64: ... porting/perlfunc.t ........ ok porting/pod_rules.t ....... ok porting/podcheck.t ........ ok porting/re_context.t ...... ok porting/readme.t .......... ok porting/regen.t ........... ok porting/ss_dup.t .......... ok porting/test_bootstrap.t .. ok porting/utils.t ........... ok ../lib/diagnostics.t ...... ok All tests successful. Files=32, Tests=43732, 164 wallclock secs ( 4.63 usr + 0.11 sys = 4.74 CPU) Result: PASS J:\dev\perl\git\perl\win32>git diff diff --git a/win32/GNUmakefile b/win32/GNUmakefile index 7e464fa3cb..6d2d561b8e 100644 --- a/win32/GNUmakefile +++ b/win32/GNUmakefile @@ -52,7 +52,7 @@ INST_TOP := $(INST_DRV)\perl # Uncomment if you want to build a 32-bit Perl using a 32-bit compiler # on a 64-bit version of Windows. # -#WIN64 := undef +WIN64 := undef # # Comment this out if you DON'T want your perl installation to be versioned. @@ -180,7 +180,7 @@ DEFAULT_INC_EXCLUDES_DOT := define # Visual C++ 2015 (aka Visual C++ 14.0) (full version or Express Edition) #CCTYPE := MSVC140 # Visual C++ 2017 (aka Visual C++ 14.1) (full version or Community Edition) -#CCTYPE := MSVC141 +CCTYPE := MSVC141 # MinGW or mingw-w64 with gcc-3.4.5 or later #CCTYPE := GCC All tests pass. The test also prevents someone accidentally committing those files with DOS line endings. Maybe the test could skip if there's no .git Tony
From: <sisyphus1 [...] optusnet.com.au>
CC: <perl5-porters [...] perl.org>
To: <perlbug-followup [...] perl.org>
Subject: Re: [perl #133033] [Win32] t/porting/pod_rules.t fails test 3 if win32/GNUmakefile has been altered
Date: Wed, 28 Mar 2018 12:54:39 +1100
Download (untitled) / with headers
text/plain 1.5k
Show quoted text
-----Original Message----- From: Tony Cook via RT Sent: Wednesday, March 28, 2018 10:33 AM To: OtherRecipients of perl Ticket #133033: Cc: perl5-porters@perl.org Subject: [perl #133033] [Win32] t/porting/pod_rules.t fails test 3 if win32/GNUmakefile has been altered On Tue, 27 Mar 2018 05:49:54 -0700, sisyphus wrote:
>> Given that editing (ie manually configuring) these Windows makefiles is >> deemed to be a valid practice, it must surely be a bug in pod_rules.t >> tests that such a practice causes a test to fail. >> I think this issue has been around for a while.
> > pod_rules.t complains only if the section of the file starting with: > > # Note that this next section is parsed (and regenerated) by pod/buildtoc > # so please check that script before making structural changes here > > is modified, which changing line endings does.
I see. When, in Wordpad, I save a change to the "configurable" section of GNUmakefile (such as a change to CCTYPE or WIN64), all line endings right throughout the file are converted to "DOS". Hence the failure. I guess not many people are building perl on Windows, and those that do probably do it in a way that doesn't fall foul of this test. (I myself often build perl in a way that enables all pod_rules.t tests to pass.)
> The test also prevents someone accidentally committing those files with > DOS line endings.
Is that an issue ? And why would that concern apply to the win32 makefiles, but not other source files ? I make alterations to numeric.c without causing tests to fail. Cheers, Rob
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 592b
On Tue, 27 Mar 2018 19:14:43 -0700, sisyphus wrote: Show quoted text
> > The test also prevents someone accidentally committing those files > > with > > DOS line endings.
> > Is that an issue ? > And why would that concern apply to the win32 makefiles, but not > other > source files ? > I make alterations to numeric.c without causing tests to fail.
It's bad for numeric.c too, but it's an easy mistake to make for win32/ makefiles as you might have noticed, see: 9114410391472d028f1e143da740e860c5045bb1 2a2bf5f4414cf2a1984ea82a90bfbb2c3384d4e1 for examples of others committing such conversions. Tony
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 493b
On Tue, 27 Mar 2018 21:22:27 -0700, tonyc wrote: Show quoted text
> It's bad for numeric.c too, but it's an easy mistake to make for > win32/ makefiles as you might have noticed, see: > > 9114410391472d028f1e143da740e860c5045bb1 > 2a2bf5f4414cf2a1984ea82a90bfbb2c3384d4e1 > > for examples of others committing such conversions. > > Tony
Really easy way to do that, using XP era Wordpad saves entire file as CRLF every time. IDK if Win 7 Wordpad always saves in CRLF too. -- bulk88 ~ bulk88 at hotmail.com
Date: Thu, 29 Mar 2018 13:14:21 +1100
Subject: Re: [perl #133033] [Win32] t/porting/pod_rules.t fails test 3 if win32/GNUmakefile has been altered
To: <perlbug-followup [...] perl.org>
From: <sisyphus1 [...] optusnet.com.au>
Download (untitled) / with headers
text/plain 1.7k
Show quoted text
-----Original Message----- From: bulk88 via RT Sent: Thursday, March 29, 2018 1:20 AM To: sisyphus1@optusnet.com.au Subject: [perl #133033] [Win32] t/porting/pod_rules.t fails test 3 if win32/GNUmakefile has been altered On Tue, 27 Mar 2018 21:22:27 -0700, tonyc wrote:
>> It's bad for numeric.c too, but it's an easy mistake to make for win32/ >> makefiles as you might have noticed, see: >> >> 9114410391472d028f1e143da740e860c5045bb1 >> 2a2bf5f4414cf2a1984ea82a90bfbb2c3384d4e1 >> >> for examples of others committing such conversions.
> > Really easy way to do that, using XP era Wordpad saves entire file as CRLF > every time. IDK if Win 7 Wordpad always saves in CRLF too.
My Win 7 wordpad does. Simplest way to avoid DOS line endings is to run dos2unix on the file before uploading - which is what I do before uploading to github. The bit I don't quite understand is why it matters if GNUmakefile in the git repo has DOS line endings or not. It's a file for use with Windows only, and DOS line endings are fine on Windows. But if there are sound reasons that the perl test suite should check that some part of the GNUmakefile has not been altered in any way, then I think this ticket should be rejected and closed. All I should really need to do is: after modifying my GNUmakefile, run dos2unix on the file before building perl. And that should allow the offending test to pass. I'm actually making a small modification to the GNUmakefile to allow numeric.c to utilize the quadmath function strtoflt128() - in order to workaround a mingw-w64 bug in strtold()'s handling of some strings. I don't think that changes anything in those areas of the GNUmakefile that are affected by the pod_rules.t test - but if it does, then I guess I should look at pod/buildtoc (if I want to fix the test failure). Cheers, Rob
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.9k
On Wed, 28 Mar 2018 19:15:47 -0700, sisyphus wrote: Show quoted text
> > > -----Original Message----- > From: bulk88 via RT > Sent: Thursday, March 29, 2018 1:20 AM > To: sisyphus1@optusnet.com.au > Subject: [perl #133033] [Win32] t/porting/pod_rules.t fails test 3 if > win32/GNUmakefile has been altered > > On Tue, 27 Mar 2018 21:22:27 -0700, tonyc wrote:
> >> It's bad for numeric.c too, but it's an easy mistake to make for > >> win32/ > >> makefiles as you might have noticed, see: > >> > >> 9114410391472d028f1e143da740e860c5045bb1 > >> 2a2bf5f4414cf2a1984ea82a90bfbb2c3384d4e1 > >> > >> for examples of others committing such conversions.
> > > > Really easy way to do that, using XP era Wordpad saves entire file as > > CRLF > > every time. IDK if Win 7 Wordpad always saves in CRLF too.
> > My Win 7 wordpad does. > Simplest way to avoid DOS line endings is to run dos2unix on the file > before > uploading - which is what I do before uploading to github. > > The bit I don't quite understand is why it matters if GNUmakefile in > the git > repo has DOS line endings or not. It's a file for use with Windows > only, and > DOS line endings are fine on Windows. > > But if there are sound reasons that the perl test suite should check > that > some part of the GNUmakefile has not been altered in any way, then I > think > this ticket should be rejected and closed. > > All I should really need to do is: > after modifying my GNUmakefile, run dos2unix on the file before > building > perl. And that should allow the offending test to pass.
I keep all of my code in LF, all code on github is in LF. I want my IDE/editor, if I copy-paste in CRLF strings from another app, to only save LF. I wanna write regexes as "\n" not "\r\n" in the find tool. Mixed LF/CRLF files are a nightmare. Pure CRLF complicates things. Everything in 2000s/2010s Windows understands LF, there is no reason to distribute CRLF files. Oh and I save some bytes on my spinning rust if I use LF instead of CRLF semi-jk -- bulk88 ~ bulk88 at hotmail.com


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org