Ticket #2024 (new bug)
t/library/pcre.t: Not honoring '--without-pcre' configuration flag
Reported by: | jkeenan | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | testing | Version: | 3.1.0 |
Severity: | medium | Keywords: | |
Cc: | fperrad, ronaldws, Util, Coke | Language: | |
Patch status: | Platform: |
Description (last modified by jkeenan) (diff)
Poking around in Smolder reports, I noticed one from Coke where failures in multiple files included t/library/pcre.t. This was surprising, because in this run Parrot was configured without PCRE.
Configure args "--cc=ccache cc" "--ccflags=-g" "--without-gettext" "--without-gmp" "--without-libffi" "--without-extra-nci-thunks" "--without-opengl" "--without-readline" "--without-pcre" "--without-zlib" "--without-threads" "--without-icu" "--cc=g++" "--link=g++" "--ld=g++" "--prefix=/Users/coke/sandbox/parrot-smoker/installed_parrot"
Looking at t/library/pcre.t, I see that it never bothers to check $PConfig{HAS_PCRE} and so proceeds to run the tests. There's a lot of code that appears to predate config/auto/pcre.pm which attempts to determine whether PCRE is present.
# if we keep pcre, we need a config test my $cmd = ( $^O =~ /MSWin32/ ) ? "pcregrep --version" : "pcre-config --version"; my $has_pcre = !Parrot::Test::run_command( $cmd, STDOUT => File::Spec->devnull , STDERR => File::Spec->devnull, ); my $pcre_libpath = ''; # It's possible that libpcre is installed in # some non-standard path... if ($has_pcre && ($^O !~ /MSWin32/)) { # Extract the library path for non-windows platforms # (in case it isn't in # the normal lookup locations) my $outfile = 'pcre-config.out'; Parrot::Test::run_command('pcre-config --prefix', STDOUT => $outfile); my $out = Parrot::Test::slurp_file($outfile); unlink $outfile; chomp $out; $pcre_libpath = "$out/lib"; }
The value of $pcre_libpath is set in this block and used subsequently in tests. Not surprisingly, since no value is ever assigned when on Windows, the tests have to be skipped for Windows.
This is clearly not a satisfactory situation. By the time we get this far into testing, we should unambiguously know whether we have PCRE or not. If we need to know a library path, we should also determine that during configuration as well.
Questions:
1. Is there anything of value in the way t/library/pcre.t tests for the presence of PCRE that ought to be incorporated into config/auto/pcre.pm?
2. The tests in this file presume we know the non-empty-string value of $pcre_libpath. Should we be determining that during configuration time as well.
Am cc-ing some people who helped with TT #1401.
Thank you very much.
kid51