| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
| |
RT #130841
Setting it before Renew can cause problems if the Renew fails.
|
|
|
|
|
|
|
| |
and provide a makefile option of the same name to control it. It is set to
'define' by default, but can be commented out or set to 'undef' in the
usual manner to switch it off and return to the legacy default behaviour
of including '.' at the end of @INC.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to the rewritten CRT in this version of Visual C++ it is no longer
possible (or at least not at all easy) to make use of the ioinfo struct,
which commit b47a847f62 (re-)introduced in order to fix RT#120091/118059.
Therefore, we effectively revert commit b47a847f62 for VS2015 onwards on
the basis that being able to build with VS2015 onwards is more important
than the RT#120091/118059 bug fix. This does unfortunately mean that perls
built with <=VS2013 will not be compatible with perls built with >=VS2015,
but they may well not have been compatible anyway because of the CRT
rewrite, and certainly wouldn't be compatible if perl builds with VS2015
were not supported!
See RT#125714 for more discussion about this.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
These programs are the same, just behave differently depending on
under which name you call it.
This is a very old script, originally dating from the perl3 era.
It has been deprecated in favour of h2xs for a long time.
In Perl 5.26, these utilities will no longer be available.
|
|
|
|
|
|
|
|
|
|
| |
This pod is intended to document all deprecations in Perl.
It will document when something became deprecated, when it is
scheduled to be actually removed, and it will offer alternatives.
Initially, we documented the undeprecation of *glob{FILEHANDLE},
and removed its entry from pod/perldiag.pod where it was left
after it being no longer deprecated.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Switch from two-argument form. Filehandle cloning is still done with the two
argument form for backward compatibility.
Committer: Get all porting tests to pass. Increment some $VERSIONs.
Run: ./perl -Ilib regen/mk_invlists.pl; ./perl -Ilib regen/regcharclass.pl
For: RT #130122
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Perl now provides a way to build perl without . in @INC by default. If you want
this feature, you can build with -Ddefault_inc_excludes_dot
Because the testing / make process for perl modules do not function well
with . missing from @INC, Perl now supports the environment variable
PERL_USE_UNSAFE_INC=1 which makes Perl behave as it previously did,
returning . to @INC in all child processes.
WARNING: PERL_USE_UNSAFE_INC has been provided during the perl 5.25 development
cycle and is not guaranteed to function in perl 5.26.
Update unit tests and default value files to work with the new %Config
variable "default_inc_excludes_dot"
|
|
|
|
|
|
|
|
|
|
| |
For windows/netware It seems that many of the recent fp definitions
have not been yet copied over there [1] [2], so went mostly by dead
reckoning [3].
[1] Note that many of them are not absolutely necessary for building.
[2] The proper updating involves doing stuff in win32, which I do not have.
[3] As far as I can tell, Windows CE does not really not have long double.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The dual-life dists affected use Devel::PPPort, so can safely use
sv_setpvs() even though it wasn't added until Perl v5.10.0.
|
| |
|
|
|
|
|
|
| |
-fix issue that CCHOME depends on CCTYPE, which in auto detect mode is
set after CCHOME so CCHOME uses uninit CCTYPE var
-also fix else vs .ELSE in makefile.mk
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a bug, if you use gmake, without a GCC in PATH (but you do have
a VC in PATH) GNUMakefile is unusable because target info fatally errors.
I usually keep a strawberry perl's /c/bin dir in PATH for dmake and gmake
on my VC builds, but in 1 build config, I installed gmake to my C:/Windows
dir and did not have SP's /c/bin dir in my PATH, so GNUMakefile was broken
in that case. This patch fixes the bug.
-move the gcc -dumpversion shell outs to the GCC only section in both mkfs
dont run gcc -dumpversion on a VC build
-dont have a default CCTYPE anymore, autodetect it, if user supplies CCTYPE
explicitly on cmd line to make tool, then dont do autodetection (its
faster by 50-100ms to manually specify CCTYPE not call gcc.exe and cl.exe
with the auto detect code), "FREE" detection is unimplemented but seems
to make no difference with VC except for an old rare "free" VC 2003
I personally use a paid VC 2003.
-silence console messages and warnings from a missing gcc.exe causing
"gcc -dumpmachine" to warn or fatally error, gmake doesn't care about
exit code, dmake does
-on dmake, use := instead of *= or =, otherwise the long for loop shell
line runs dozens of times (multiple eval problem)
-on dmake, since GCCBIN macro doesn't exist and dmake mfk is "simpler"
than gmake just call gcc.exe always and not a prefixed version of GCC for
the GCCTARGET macro, it isn't used outside the autodetection code anyways
and if a user neglected to specify CCTYPE it is assumed they neglected to
specify GCCCROSS too
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The changes to parallelize win32 perl builds with dmake and gmake
assumed that ppport.h only provided macros and functions that are
already provided by the latest perl.
This turns out not to be the case, preventing the building of
a new Scalar-List-Utils with dmake and gmake.
I only briefly considered changing Scalar-List-Utils - the difference
in build systems is what lead to the failure, so properly build ppport.h
so that all Win32 builds have a full ppport.h just as POSIXish builds
do.
|
|
|
|
| |
(including regen/opcode.pl)
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
As requested by khw++
Until the relevant symbol is used, HAS_STRERROR_L must be mentioned
explicitly in metaconfig.h.
This corresponds to metaconfig d0838744f03cfe7642950ea91dd48f575d0bfd15.
|
|
|
|
|
|
|
|
|
| |
As requested by khw++
Until the relevant symbol is used, HAS_QUERYLOCALE must be mentioned
explicitly in metaconfig.h.
This corresponds to metaconfig 541f0dd272df4f9326996727898393ac8f6626f7.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Encountered while testing locally on Windows 7 x64.
cmd.exe stores the current directory for each drive as entries in the
environment, like:
C:\Users\tony>set "" | findstr "^="
=::=::\
=C:=C:\Users\tony
=D:=D:\ASM1061
When a Win32 build of perl built with USE_IMP_SYS starts up it saves
the current directories of each drive in a per-thread structure so
that each pseudo-forked process can have it's own set of drive current
directories.
If you run an external command, some versions of cmd.exe will add
an entry to the environment storing the result of that command, for
example:
C:\Users\tony>set "" | find "ExitCode"
C:\Users\tony>git status
fatal: Not a git repository (or any of the parent directories): .git
C:\Users\tony>set "" | find "ExitCode"
=ExitCode=00000080
which is similar to the current directory entries.
The sloppy parsing by VDir::FromEnv[WA]() would treat that as a
current directory entry for the E: drive, copying the "tCode=...."
into the current directory. Normally these values include a leading
drive letter and \, like "E:\", but this case leaves us without that.
Later, when harness spawns the child process it builds a new environment
block, including the drive current directories, which is done by
VDir::BuildEnvironmentSpace(). This, rather than using the index of
the drive to build the "=C:=..." entries above, uses the first
letter of the stored entry, so the environment block would have
something like:
t:=tCode=00000080
which the child perl would treat as the current directory for the T:
drive.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|