search

Perl / perl5

🐪 The Perl programming language
https://dev.perl.org/perl5/
Other
1.91k stars 542 forks source link

[Win32] t/porting/pod_rules.t fails test 3 if win32/GNUmakefile has been altered #16481

Open p5pRT opened 6 years ago

p5pRT commented 6 years ago

Migrated from rt.perl.org#133033 (status was 'open')

Searchable as RT133033$

p5pRT commented 6 years ago

From @sisyphus

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

p5pRT commented 6 years ago

From @tonycoz

On Tue\, 27 Mar 2018 05​:49​:54 -0700\, sisyphus wrote​:

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

Inline Patch ```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

p5pRT commented 6 years ago

The RT System itself - Status changed from 'new' to 'open'

p5pRT commented 6 years ago

From @sisyphus

-----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

p5pRT commented 6 years ago

From @tonycoz

On Tue\, 27 Mar 2018 19​:14​:43 -0700\, sisyphus wrote​:

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

p5pRT commented 6 years ago

From @bulk88

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.

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

p5pRT commented 6 years ago

From @sisyphus

-----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

p5pRT commented 6 years ago

From @bulk88

On Wed\, 28 Mar 2018 19​:15​:47 -0700\, sisyphus wrote​:

-----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