New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Win32] t/porting/pod_rules.t fails test 3 if win32/GNUmakefile has been altered #16481
Comments
From @sisyphusHi, If the win32/GNUmakefile has been altered in any way (even just converting C:\_32\comp\perl-5.27.10-mod>perl t/porting/pod_rules.t Otherwise all tests pass. I think it likely (untested) that the same test fails with win32/Makefile or Cheers, Summary of my perl5 (revision 5 version 27 subversion 10) configuration: Platform: Characteristics of this binary (from libperl): |
From @tonycozOn Tue, 27 Mar 2018 05:49:54 -0700, sisyphus wrote:
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 is modified, which changing line endings does. If I modify only CCTYPE and WIN64: ... J:\dev\perl\git\perl\win32>git diff Inline Patchdiff --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----- On Tue, 27 Mar 2018 05:49:54 -0700, sisyphus wrote:
I see. I guess not many people are building perl on Windows, and those that do
Is that an issue ? Cheers, |
From @tonycozOn Tue, 27 Mar 2018 19:14:43 -0700, sisyphus 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: for examples of others committing such conversions. Tony |
From @bulk88On Tue, 27 Mar 2018 21:22:27 -0700, tonyc wrote:
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. -- |
From @sisyphus-----Original Message----- On Tue, 27 Mar 2018 21:22:27 -0700, tonyc wrote:
My Win 7 wordpad does. The bit I don't quite understand is why it matters if GNUmakefile in the git But if there are sound reasons that the perl test suite should check that All I should really need to do is: I'm actually making a small modification to the GNUmakefile to allow Cheers, |
From @bulk88On Wed, 28 Mar 2018 19:15:47 -0700, sisyphus wrote:
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 -- |
Migrated from rt.perl.org#133033 (status was 'open')
Searchable as RT133033$
The text was updated successfully, but these errors were encountered: