| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Since x2p has been removed, there is no translators target in the
Makefile, but it was still referenced in some definitions. This was a
fatal error for Solaris make.
|
|
|
|
|
|
|
|
|
| |
This only affected 'make test' for cross-compilation builds; in
those, we try to copy files relevant to 'make test' to the target
system.
Since Module::Build is no longer part of the core, no need to
try to copy it over.
|
|
|
|
|
| |
This removes find2perl, s2p and a2p from core. They have all been
released to CPAN as separate distributions.
|
|
|
|
| |
For: https://rt.perl.org/Ticket/Display.html?id=121978
|
|
|
|
|
|
|
|
|
|
|
|
| |
Output for each test will be printed inline when it finishes.
Sample usage (loud):
TEST_JOBS=9 make test.valgrind
Sample usage (quiet):
VG_OPTS='-q --leak-check=no --show-reachable=no' TEST_JOBS=9 make test.valgrind
|
|
|
|
|
|
|
| |
I ran regen/lib_cleanup.pl because porting/regen.t was failing.
No I don't understand this area at all. And I don't think 'make realclean'
is doing what its supposed to be doing.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
This uses sed to avoid the problem of the sh not being modern enough.
The commiter moved the sed so it appears in just one place.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit f0aff2daa44923f600f6e1f2429a2add2214a9d5
"Add support for test.valgrind parallel testing"
This patch was accidentally pushed (by me); it breaks some things. We
will wait to add this support until after 5.20
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
# New Ticket Created by Matthew Horsfall
# Please include the string: [perl #121431]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/Ticket/Display.html?id=121431 >
This is a bug report for perl from wolfsage@gmail.com,
generated with the help of perlbug 1.39 running under perl 5.14.2.
-----------------------------------------------------------------
[Please describe your issue here]
The included patch allows test.valgrind to run tests in parallel.
Valgrind output for each test will be printed out after the test
completes, with the name of the test prefixing every line.
Example usage might be:
TEST_JOBS=8 make test.valgrind VALGRIND='valgrind -q' 2>&1 | tee out.txt
-q is needed to ensure only *errors* are captured, otherwise the output will
be much louder than it already is. (Perhaps this should be the default mode?)
[Please do not change anything below this line]
-----------------------------------------------------------------
|
| |
|
|
|
|
|
| |
Currently this is only used during make test, and allows setting
the environment of the target before running tests.
|
|
|
|
|
|
| |
t/TEST uses this to determine which extensions to run tests for;
if it's missing, it'll end up running everything, which means a ton of
failures from, say, Win32 and VMS if cross-compiling to Linux.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a bit of a step backwards, but we want to run this in
the target platform when cross-compiling to some unusual setups,
like ASCII -> EBCDIC.
What this branch introduces is a third "path" for generate_uudmap:
* If we are doing a native build, just build it as usual and run it.
* If we're cross-compiling, and either -Dhostgenerate was specified OR
if it was left empty, which is the default case, then create
a host generate_uudmap and run it locally
* Finally, if are cross-compiling and were built with -Uhostgenerate,
then build generate_uudmap for the target and run it there, bringing
back the resulting headers.
|
| |
|
| |
|
|
|
|
| |
LD_LIBRARY_PATH=...
|
|
|
|
|
|
|
| |
Along with the previous commit, this enables us to run 'make test'
on the host and have the tests run on the target. We do this by
calling ./Cross/run ./TEST with -cwd $targetdir/t, and setting its
LD_LIBRARY_PATH to $targetdir, so that libperl.so is found.
|
|
|
|
|
|
|
|
|
|
|
| |
This is groundwork to enable us to do this:
$ make
$ make test
on the host, and have the test suite be run on the target.
Currently this list of files is hand-maintained.
|
|
|
|
|
| |
HOST_PERL is often set while cross compiling, so we can run the
install from the host machine.
|
|
|
|
|
| |
Note we can only substitute the system perl for scripts that do not require Config
as it complains about non-matching Perl versions.
|
| |
|
| |
|
|
|
|
| |
local use
|
|
|
|
| |
When cross-compiling we want to run miniperl etc on the compile host, not the test target
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current UNIX build system does a strange thing to generate the
appropriate command-line to compile a particular src file. It calls
the cflags shell script, which
1) echoes to stdout the command line needed to compile the specified
file (excluding the name of the src file itself), e.g.
cc -c -Dfoo -Wbar ...
2) echoes the same thing to stderr, prefixied with ' CCCMD ='
Make then does
`sh cflags foo.o` foo.c
the cflags output to stdout is captured by the backticks, and is used
by make as the command line to run (with the foo.c appended). This run is
silent. The output to stderr isn't captured, and gets displayed. So the
user sees:
$ make
`sh cflags foo.o` foo.c
CCCMD = cc -c -Dfoo -Wbar ...
...
This is annoying for 2 reasons:
1) you don't get a simple command-line displayed which you could do a
simple cut and paste with (e.g. when you want to recompile a specific
source file, but alter the flags).
2) The make generates output on stderr, even when then there aren't any
errors. So "make 2>errs" can't be used to quickly spot warnings and
errors.
This commit fixes this by making cflags just output the cc command and
flags to stdout, then get Makefile to call it twice, once to echo
the command-line (on stdout), and once to execute it with backticks.
So the make output is now:
$ make
cc -c -Dfoo -Wbar ... foo.c
...
There is some stuff in Makefile.SH related to cross-compiling, which this
commit make have broken. Specifically the CCCMD and CCCMDSRC macros
have been changed in the normal case to remove backticks (and add them to
the make rules instead), but not for the cross compilation route.
The CC* defs in the cross-compilation case have a trailing -I$(CROSS_LIB)
outside of the backticks, which compilates matters.
However, in the subdir Cross/, there appears to be separate (and
divergent) copies of Makefile.SH and cflags, so maybe the files
I edited are no longer used for cross-compilation????
(followup: according to
<20131204170112.GA2490@iabyn.com>
the cross-compiling stuff I mentioned above has bit-rotted, and I don't
need to worry about it)
|
| |
|
| |
|
|
|
|
|
|
|
| |
This also moves the indirect dependency on stdbool.h to its
own file, rather than being pulled in for all of perl.c, for
those cases where one may want to test using other definitions
of bool.
|
| |
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: Chris 'BinGOs' Williams <chris@bingosnet.co.uk>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When perl is build with a shared perl library, $(LDLIBPTH) is used to prefix
the appropriate LD_LIBRARY_PATH=... before commands in the Makefile so that
the uninstalled ./perl will be able to find it.
Commit c4f23d77f4b3486a (in May 1998) added the code for LDLIBPTH, but also
added it to the default command line used to invoke $(CC) to link perl and
miniperl. These commands don't need to run ./perl, hence the use of
$(LDLIBPTH) is superfluous here. Removing it makes the code simpler.
$(LDLIBPTH) was first removed in commit d182087b9c1b8811 (April 2003), but
that change was reverted by commit f913803b6e67ae4c (in Aug 2003) as part of
an attempt to fix problems reported by a perl smoker on a platform where the
C compiler is actually a Perl wrapper script. However, from subsequent
discussion it seems that the reversion didn't actually fix the problem, and
both the documentation of LD_LIBRARY_PATH and attempting to replicate the
smoker's setup suggest that this particular change is independent of the
problem. I can't replicate the smoker's reported problems building a shared
library perl with (or without) this commit on a current Power Linux machine
using a Perl script to wrap the C compiler, where the #! line on that Perl
script is an install of perl 5.8.0 also using a shared perl library. Hence
I'm confident that this change is independent of the true cause of the
smoker's problems. See the discussion in RT #23212 for more details.
|
| |
|
|
|
|
|
| |
The Win32 line C<-del /f *.def *.map> and the start of the Unix line
C<rm -f so_locations> are unlikely to change.
|
|
|
|
|
| |
Rules to clean lib/ExtUtils/CBuilder/t and lib/ExtUtils/ParseXS/t haven't
been needed since the modules were moved to cpan/ and dist/
|
| |
|
|
|
|
|
|
|
|
|
| |
Whilst there are still several differences between what's in core and what's
in the CPAN tarball, moving the files in core to their own directory with
the same layout as the CPAN distribution simplifies things.
Somewhat surprisingly, none of the toolchain modules C<use version;> so
there's no need to add to lib/buildcustomize.pl
|
|
|
|
|
|
|
|
|
| |
Previously the Makefile's install-notify target built extra.install just like
the other 5 install targets. However, the other 5 actually install perl,
whereas install-notify (a.k.a. no-install) runs installperl and installman
with the --notify option (formerly -n), to cause them to print what they would
do but take no action. Hence if -Dextras was used, make no-install would
actually install the extra modules, but nothing else. This is inconsistent.
|
|
|
|
|
|
|
|
|
|
|
| |
This eliminates 6 recursive calls from Makefile to itself. As five of these
are generated from a loop in Makefile.SH, this isn't massive code
duplication. It's not obvious how to merge the sixth without increasing the
code complexity.
Additionally, if the user has specified extra modules to download and build
from CPAN using Configure's -Dextra, this avoids building perl, the non-XS
modules and the CPAN modules twice on make install.
|