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

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

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

The test also prevents someone accidentally committing those files with DOS line endings.

Maybe the test could skip if there's no .git

Tony

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

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

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

9114410
2a2bf5f

for examples of others committing such conversions.

Tony

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

9114410
2a2bf5f

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

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

9114410
2a2bf5f

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

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

9114410
2a2bf5f

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