Re: [RELEASE CANDIDATE] Apache-Test-1.27 RC2
On Wed, 12 Oct 2005, Philip M. Gollucci wrote: A release candidate for Apache-Test 1.27 is now available. http://people.apache.org/~pgollucci/at/Apache-Test-1.27-RC2.tar.gz Please take the time to exercise the candidate through all your existing applications that use Apache-Test and report back successes or failures. Builds and tests fine on - linux: Apache/2.0.54 (prefork) - win32: Apache/2.0.54 (winnt) -- best regards, randy
Re: [PATCH] add ldd/otool output to bug reports
On Mon, 12 Sep 2005, Philip M. Gollucci wrote:
If this point was reached, it would break Win32, plus
any other system which didn't have an ldd in the PATH.
Perhaps Apache::TestConfig::which() could be used to
see if an ldd() [or otool()] is present, and skip this
part if it's not found?
I guess qx{} is different on win32 ?
Take from example on my FBSD box which does not have 'otool'
% perl -e 'my $command = otool -L /bin/ls; qx{$command}; print \ndone.\n'
done.
I don't think it matters, but at rate, Apache::TestConfig::which() will
better find ldd/otool.
I think the use of which() is better - what would have
happened before is that a message:
'ldd' is not recognized as an internal or external
command, operable program, or batch file.
would appear with Win32, which would be confusing.
Does win32 have an equivalent?
There are utilities on Win32 that give extra information
like this; I'll take a look later at them to see which
might be useful. But for now, I'd suggest doing it without
Win32, as you have it. Thanks.
--
best regards,
randy
Re: [PATCH] add ldd/otool output to bug reports
On Fri, 9 Sep 2005, Philip M. Gollucci wrote:
For both mp2bug and A-T
Question, why does A-T call it OSX and mp2 call it DARWIN ... should we sync
one way or the other ?
Index: lib/ModPerl/Config.pm
===
--- lib/ModPerl/Config.pm (revision 279736)
+++ lib/ModPerl/Config.pm (working copy)
@@ -18,9 +18,11 @@
use Apache2::Build ();
use Apache::TestConfig ();
+use Apache::TestConfigData ();
use File::Spec ();
use constant WIN32 = Apache2::Build::WIN32;
+use constant DARWIN = Apache2::Build::WIN32;
sub as_string {
my $build = Apache2::Build-build_config;
@@ -53,8 +55,19 @@
$command = $httpd -V;
$cfg .= \n\n*** $command\n;
$cfg .= qx{$command};
-}
-else {
+
+# Add the dynamic link information
+# For now, assume its in our path... its there a better way ?
+if (DARWIN) {
+$command = otool $httpd;
+}
+else {
+$command = ldd $httpd;
+}
+
+$cfg .= \n*** $command\n;
+$cfg .= qx{$command};
+} else {
$cfg .= \n\n*** The httpd binary was not found\n;
}
Index: Apache-Test/lib/Apache/TestConfig.pm
===
--- Apache-Test/lib/Apache/TestConfig.pm(revision 279734)
+++ Apache-Test/lib/Apache/TestConfig.pm(working copy)
@@ -1837,7 +1837,19 @@
$command = $httpd -V;
$cfg .= \n*** $command\n;
$cfg .= qx{$command};
-}
+
+# Add the dynamic link information
+# For now, assume its in our path... its there a better way ?
+if (OSX) {
+$command = otool $httpd;
+}
+else {
+$command = ldd $httpd;
+}
+
+$cfg .= \n*** $command\n;
+$cfg .= qx{$command};
+}
else {
$cfg .= \n\n*** The httpd binary was not found\n;
}
If this point was reached, it would break Win32, plus
any other system which didn't have an ldd in the PATH.
Perhaps Apache::TestConfig::which() could be used to
see if an ldd() [or otool()] is present, and skip this
part if it's not found?
--
best regards,
randy
Re: Unable to run t/ssl tests.
On Fri, 22 Jul 2005, William A. Rowe, Jr. wrote: Well now; rm -rf t , and svn up, gives me the original error attempting to create 'serial', a 'serial.old' lingers during the config phase. Just as a couple of checks: - does perl t/TEST -clean clean out the t\conf\ssl\ca directory completely? - is openssl writing things to the t\conf\ssl\ca\asf directory? -- best regards, randy
Re: Unable to run t/ssl tests.
On Fri, 22 Jul 2005, William A. Rowe, Jr. wrote: On Win32... Using openssl 0.9.8, httpd 2.1-dev (current) and perl-framework (current)... and I end up in a loop between running t/TEST -clean and t/TEST -apxs g:/path/to/apxs with this error, every time; The Subject's Distinguished Name is as follows countryName :PRINTABLE:'US' stateOrProvinceName :PRINTABLE:'California' localityName :PRINTABLE:'San Francisco' organizationName :PRINTABLE:'ASF' organizationalUnitName:PRINTABLE:'httpd-test/dsa-des3-test' commonName:PRINTABLE:'localhost' emailAddress :IA5STRING:'test-dev@httpd.apache.org' Certificate is to be certified until Jul 22 21:36:28 2006 GMT (365 days) Write out database with 1 new entries unable to rename serial to serial.old reason: File exists [ error] configure() has failed: system ca -policy policy_anything -in csr/server_des3_dsa.csr -out certs/server_ des3_dsa.crt -passin pass:httpd -config conf/server_des3_dsa.cnf -batch extensions comment failed (exit status=1) at G:\built\perl-framework\blib\lib/Apache/TestSSLCA.pm line 172. [warning] forcing Apache::TestConfig object save [warning] run 't/TEST -clean' to clean up before continuing Does this look familiar to anyone? That does seem vaguely familiar, but I just tried the perl-framework on Win32 with openssl-0.9.7g and Apache/2.0.54, and the certificates got generated OK, and all the t/ssl/ tests passed. I'll try upgrading openssl to see if there's any change. -- best regards, randy
Re: apxs calls on Win32
On Tue, 7 Dec 2004, Stas Bekman wrote:
As soon as you see dup like this, think refactoring :) e.g. add
untaint_path(), that does the work and call it:
local $ENV{PATH}) = untaint_path($ENV{PATH});
Otherwise +1.
And of course this wrapper should probably used in open_cmd too!
Here's a patch that does that:
==
Index: lib/Apache/TestConfig.pm
===
--- lib/Apache/TestConfig.pm(revision 56)
+++ lib/Apache/TestConfig.pm(working copy)
@@ -1045,12 +1045,8 @@
my($self, $cmd) = @_;
# untaint some %ENV fields
local @ENV{ qw(IFS CDPATH ENV BASH_ENV) };
+local $ENV{PATH} = untaint_path($ENV{PATH});
-# Temporarily untaint PATH
-(local $ENV{PATH}) = ( $ENV{PATH} =~ /(.*)/ );
-# -T disallows relative directories in the PATH
-$ENV{PATH} = join ':', grep !/^\./, split /:/, $ENV{PATH};
-
# launder for -T
$cmd = $1 if $cmd =~ /(.*)/;
@@ -1663,7 +1659,8 @@
return unless $self-{APXS};
my $val;
unless (exists $self-{_apxs}{$q}) {
-local @ENV{ qw(PATH IFS CDPATH ENV BASH_ENV) };
+local @ENV{ qw(IFS CDPATH ENV BASH_ENV) };
+local $ENV{PATH} = untaint_path($ENV{PATH});
my $devnull = devnull();
my $apxs = shell_ready($self-{APXS});
$val = qx($apxs -q $q 2$devnull);
@@ -1684,6 +1681,17 @@
$self-{_apxs}{$q};
}
+# Temporarily untaint PATH
+sub untaint_path {
+my $path = shift;
+($path) = ( $path =~ /(.*)/ );
+# win32 uses ';' for a path separator, assume others use ':'
+my $sep = WIN32 ? ';' : ':';
+# -T disallows relative directories in the PATH
+$path = join $sep, grep !/^\./, split /$sep/, $path;
+return $path;
+}
+
sub pop_dir {
my $dir = shift;
==
I tried committing it, but was denied access (I ensured I
did a co with https); perhaps some permissions need
adjusting (I did have commit access under cvs).
--
best regards,
randy
Re: apxs calls on Win32
On Sun, 5 Dec 2004, Stas Bekman wrote:
Randy Kobes wrote:
If apxs is installed on Win32, it is usually specified as a
.bat file. In querying apxs in apxs() of Apache::TestConfig,
however, Win32 needs both the path to cmd.exe (for running a
.bat command) and to Perl (in order to run apxs.bat) in
order to get something from
$val = qx($apxs -q $q 2$devnull);
This diff:
If it's only win32 case then +1 but if other platforms may have the same
problem, may be it's better to blindly launder $ENV{PATH} like we do in a
few other places (in which case there will be no need for this change, as
the right paths will be there already, correct?)
That's right - what about the following, copied from
the open_cmd sub of Apache::Build (for Win32, this needs
to use the ';' as the directory separator within $ENV{PATH},
rather than ':'.
==
Index: lib/Apache/TestConfig.pm
===
--- lib/Apache/TestConfig.pm(revision 110064)
+++ lib/Apache/TestConfig.pm(working copy)
@@ -1043,7 +1043,8 @@
# Temporarily untaint PATH
(local $ENV{PATH}) = ( $ENV{PATH} =~ /(.*)/ );
# -T disallows relative directories in the PATH
-$ENV{PATH} = join ':', grep !/^\./, split /:/, $ENV{PATH};
+my $sep = WIN32 ? ';' : ':';
+$ENV{PATH} = join $sep, grep !/^\./, split /$sep/, $ENV{PATH};
# launder for -T
$cmd = $1 if $cmd =~ /(.*)/;
@@ -1657,7 +1658,12 @@
return unless $self-{APXS};
my $val;
unless (exists $self-{_apxs}{$q}) {
-local @ENV{ qw(PATH IFS CDPATH ENV BASH_ENV) };
+local @ENV{ qw(IFS CDPATH ENV BASH_ENV) };
+# Temporarily untaint PATH
+(local $ENV{PATH}) = ( $ENV{PATH} =~ /(.*)/ );
+# -T disallows relative directories in the PATH
+my $sep = WIN32 ? ';' : ':';
+$ENV{PATH} = join $sep, grep !/^\./, split /$sep/, $ENV{PATH};
my $devnull = devnull();
my $apxs = shell_ready($self-{APXS});
$val = qx($apxs -q $q 2$devnull);
=
--
best regards,
randy
Re: apxs calls on Win32
On Tue, 7 Dec 2004, Stas Bekman wrote:
Randy Kobes wrote:
[ ... ]
==
Index: lib/Apache/TestConfig.pm
===
--- lib/Apache/TestConfig.pm(revision 110064)
+++ lib/Apache/TestConfig.pm(working copy)
@@ -1043,7 +1043,8 @@
# Temporarily untaint PATH
(local $ENV{PATH}) = ( $ENV{PATH} =~ /(.*)/ );
# -T disallows relative directories in the PATH
-$ENV{PATH} = join ':', grep !/^\./, split /:/, $ENV{PATH};
+my $sep = WIN32 ? ';' : ':';
+$ENV{PATH} = join $sep, grep !/^\./, split /$sep/, $ENV{PATH};
# launder for -T
$cmd = $1 if $cmd =~ /(.*)/;
@@ -1657,7 +1658,12 @@
return unless $self-{APXS};
my $val;
unless (exists $self-{_apxs}{$q}) {
-local @ENV{ qw(PATH IFS CDPATH ENV BASH_ENV) };
+local @ENV{ qw(IFS CDPATH ENV BASH_ENV) };
+# Temporarily untaint PATH
+(local $ENV{PATH}) = ( $ENV{PATH} =~ /(.*)/ );
+# -T disallows relative directories in the PATH
+my $sep = WIN32 ? ';' : ':';
+$ENV{PATH} = join $sep, grep !/^\./, split /$sep/, $ENV{PATH};
my $devnull = devnull();
my $apxs = shell_ready($self-{APXS});
$val = qx($apxs -q $q 2$devnull);
As soon as you see dup like this, think refactoring :) e.g. add
untaint_path(), that does the work and call it:
local $ENV{PATH}) = untaint_path($ENV{PATH});
Otherwise +1.
And of course this wrapper should probably used in open_cmd too!
OK, I'll do that - thanks!
Also is there some File::Spec thingy that defines record
separator in paths?
I looked through there - there's not one specifically
defined. There are special cases for various platforms:
Mac = uses ',', but needs $ENV{Commands}, not $ENV{PATH}
OS2 = uses ';', but also translates '\' to '/'
VMS = uses a different $ENV variable
So some of these (eg, Mac and VMS) would require special
handling just to get at the equivalent of $ENV{PATH}.
Is leaving it just as is OK for the moment (using ';' for
WIN32, ':' otherwise), and if someone has problems with it,
we can fix it then?
Also, I haven't tried it yet, but just to make sure the
email messages go to the right place - can one do a commit
to Apache-Test from within modperl-2.0 svn (from within
the Apache-Test subdirectory)?
--
best regards,
randy
apxs calls on Win32
If apxs is installed on Win32, it is usually specified as a
.bat file. In querying apxs in apxs() of Apache::TestConfig,
however, Win32 needs both the path to cmd.exe (for running a
.bat command) and to Perl (in order to run apxs.bat) in
order to get something from
$val = qx($apxs -q $q 2$devnull);
This diff:
==
Index: lib/Apache/TestConfig.pm
===
--- lib/Apache/TestConfig.pm(revision 109825)
+++ lib/Apache/TestConfig.pm(working copy)
@@ -1658,6 +1658,12 @@
my $val;
unless (exists $self-{_apxs}{$q}) {
local @ENV{ qw(PATH IFS CDPATH ENV BASH_ENV) };
+# need path to Perl and to cmd.exe on Win32
+if (WIN32) {
+$ENV{PATH} = sprintf(%s;%s,
+ dirname($ENV{COMSPEC}),
+ dirname($self-{vars}-{perl}));
+}
my $devnull = devnull();
my $apxs = shell_ready($self-{APXS});
$val = qx($apxs -q $q 2$devnull);
=
populates $ENV{PATH} with the needed paths so that these
calls succeeed.
--
best regards,
randy
Re: httpd-test pages need to be updated to point to svn not cvs
On Tue, 30 Nov 2004, Stas Bekman wrote: http://httpd.apache.org/test/ is outdated (s/cvs/svn/)... thanks. I just changed, via svn, the site/docs/test/index.html and site/xdocs/test/index.xml pages to reflect this. However, I just wanted to verify that, to get the changes on the site itself, one must $ ssh cvs.apache.org $ cd /www/httpd.apache.org/test $ svn up Thanks. -- best regards, randy
Re: Apache-Test module skeletons
On Fri, 9 Jul 2004, David Wheeler wrote:
On Jul 9, 2004, at 1:09 PM, Stas Bekman wrote:
There is no Apache.pm in mp2. You probably wanted to say:
requires = { 'mod_perl' = 0,
Right. In fact, it should probably be
requires = { 'mod_perl' = '1.0',
in the MP1 example, and
requires = { 'mod_perl' = '1.99',
in the MP2 example, yes?
Assuming this is for the benefit of CPAN/CPANPLUS to install
dependencies, doesn't this run into a couple of problems
that, in particular, Stas has raised:
- CPAN doesn't yet support multiple module versions, only
the latest (which currently is mp1, as mp2 is marked as
a development version);
- if someone had mp2 installed in an Apache2/ subdirectory,
CPAN/CPANPLUS wouldn't see it unless somehow 'use Apache2'
was invoked to adjust @INC;
What about requiring 'Apache' for mp1-related modules (since
'Apache' doesn't exist within mp2), and for mp2 modules,
requiring 'Apache2' (which doesn't exist within mp1)?
--
best regards,
randy
Re: Apache-Test module skeletons
On Fri, 9 Jul 2004, David Wheeler wrote:
On Jul 9, 2004, at 1:45 PM, David Wheeler wrote:
use 5.00503;
use Apache::TestMB;
Apache::TestMB-new(
module_name= 'Apache::Test::Skeleton',
license= 'perl',
requires = { 'mod_perl' = = 1.0, 1.99,
},
build_requires = { Test::More = 0,
},
)-create_build_script;
Oh, and FWIW, CPANPLUS should soon have the ability to check such a
spec. Not sure that CPAN.pm ever will, though.
Regards,
David
But won't the CPAN indices (which are used by both CPAN.pm
and CPANPLUS.pm) still just recognize one version of
mod_perl.pm? Either the current one associated with mp1, or,
when mp2 is out of development, that associated with mp2
(assuming mod_perl.pm of mp2 has a higher version compared
to that of mp1). Or will CPANPLUS go beyond the CPAN
indices?
One (qualitatively similar) example is the GD module, for
which there's two major (incompatible) versions, 1 and 2.
Currently CPAN.pm reports GD as being version 2.12, and so
to install an earlier version 1.x, you have to tell CPAN.pm
explicitly which distribution you want to install.
--
best regards,
randy
Re: Error running apache test
On Tue, 22 Jun 2004, Abhishek Khandelwal wrote: I am getting another strange problem. I compile and install apache 2.0.49 for both fedora core 1 and red-hat linux. Everything seems okay, and installs properly. When I start httpd manually, it start running and when I do wget using http://localhost It works fine in both the machines. But, when I run the test provided my perl-test-framework. And try to run the server using t/TEST -httpd-start, the server starts perfectly on Fedora core but it dies immediately with exit code 255 on Red-hat machine. Looking at the error log, in t/log/error_log directory, I see the error: [error] (38)Function not implemented: Cannot create SSLMutex In the ssl portion of your system httpd.conf, if the SSLMutex directive is not given as SSLMutex default does changing it to that help? -- best regards, randy kobes
Re: Error running apache test
On Tue, 22 Jun 2004, Abhishek Khandelwal wrote: Where exactly I put this? In the conf file generated by test, which is in t/conf/httpd.conf or even before compiling and building test, I change the original httpd.conf? Try changing the original first - I think Apache-Test should pick up this setting. Also, where exactly do I put this SSLMutex default? When installing Apache, assuming a fresh install, this directive probably appears somewhere in a sample ssl configuration file. -- best regards, randy
Re: Error running apache test
On Tue, 22 Jun 2004, Abhishek Khandelwal wrote: I changed original ssl.conf to the SSLMutex default as shown below. # Semaphore: # Configure the path to the mutual exclusion semaphore the # SSL engine uses internally for inter-process synchronization. #SSLMutex file:/opt/oss/var/apache2/run/ssl_mutex SSLMutex default Then I rebuild the test and try to run the test. But still my error log shows SSLMutex not created error. Does the above change to SSLMutex also appear in the config file generated by Apache-Text beneath t/conf/? If not, try doing a make clean to clean out the old stuff, and then rebuilding. -- best regards, randy
Re: [NOMINATE] commit access for david wheeler
On Wed, 23 Jun 2004, Geoffrey Young wrote: hi all... as suggested by stas in a recent thread, it's about time we gave david commit access to the perl-framework - he has been actively helping with the project for as long as I can remember, from mac-specific stuff to lots of great work on the (often thin) docs. and now he is working feverishly on integrating Module::Build support into Apache-Test, which is in itself a noble effort worthy of commit rights. so, here is my +1. +1 - great idea! -- best regards, randy
Re: Apache::TestMB
On Mon, 21 Jun 2004, David Wheeler wrote: [ ... ] * This isn't commented in the code I sent you, but I'll note it: I didn't implement cmodules or cmodules_clean actions. They appear simple, but they seem to depend on `make` rather than Module::Build. Stas, are these just that simple? Should I expect that there'd be a Makefile in the cmodules directory? Or might it be Module::Build-based? I guess the real question is, where does that Makefile come from? Right now the Makefile is generated by methods within Apache/TestConfigC.pm, which generally consists of calling the apxs utility to compile the module (as well as implementing a 'clean' target). In principle I think this could be done via Module::Build with an appropriate Build.PL and the corresponding changes within Apache/TestConfigC.pm to call it. -- best regards, randy kobes
Re: [Module::Build] Re: Apache::TestMB
On Tue, 22 Jun 2004, David Wheeler wrote: On Jun 22, 2004, at 7:32 AM, Randy Kobes wrote: Right now the Makefile is generated by methods within Apache/TestConfigC.pm, which generally consists of calling the apxs utility to compile the module (as well as implementing a 'clean' target). In principle I think this could be done via Module::Build with an appropriate Build.PL and the corresponding changes within Apache/TestConfigC.pm to call it. Okay. I've put in some placeholder methods for this; Randy, can you add the necessary code? Sure, it should be relatively straightforward ... But I'd like to get, especially, Stas' opinion on this - adding this in will necessarily introduce a few branches in the Apache/TestConfigC.pm code related to, first of all, whether to write a Makefile.PL or a Build.PL (and the ensuing different syntax), and then secondly, how to use them. -- best regards, randy
Re: more on the perl-framework on windows
On Fri, 26 Mar 2004, Rodent of Unusual Size wrote: Geoffrey Young wrote: if apxs is being invoked but isn't available you may have a leftover TestConfigData.pm sitting around which you can safely remove. or you didn't explicitly pass -httpd or something like that, which you ought to be able to do via t/TEST -conf -httpd /path/to/httpd as well. the problem is that there *is* an apxs.pl, but no development tools. apxs came with the installation; the server wasn't built on this system. i have built the c modules and i'm trying to put them in place so the framework will use them without trying to frickin' build them. however, it apparently wants to run apxs even though the module binaries exist. what's triggering that? why won't it use what's there without trying to create them itself? If you put the compiled modules in place, and then run 'nmake test', is the problem that things get cleaned out first (erasing the binaries), or that it just tries to recompile things? On my system (which has VC++), 'nmake test' first cleans things out, which erases previously built modules. -- best regards, randy
Re: testing apache 1.3 on windows
On Tue, 16 Mar 2004, Rodent of Unusual Size wrote: and a 'perl t\TEST -config' blowes up trying to build mod_random_chunk (unresolved symbols _random and _srandom). I couldn't find the _random or _srandom symbols in a system library, but changing these to rand() and srand() in mod_random_chunk.c seems to work OK. -- best regards, randy
Re: testing apache 1.3 on windows
On Wed, 17 Mar 2004, Rodent of Unusual Size wrote: Randy Kobes wrote: I couldn't find the _random or _srandom symbols in a system library, but changing these to rand() and srand() in mod_random_chunk.c seems to work OK. mm. i've ifdef'd those for WIN32 and will commit it; if anyone cares to verify that s/rand() are universally suitable replacements for s/random(), the ifdef can go. thanks, randy! I found this in the rand man page on Linux: The versions of rand() and srand() in the Linux C Library use the same random number generator as random() and srandom(), so the lower-order bits should be as random as the higher-order bits. However, on older rand() implementations, the lower-order bits are much less random than the higher-order bits. So it looks like they're not equivalent on older implementations. -- best regards, randy
Re: testing apache 1.3 on windows
On Tue, 16 Mar 2004, Rodent of Unusual Size wrote: Randy Kobes wrote: There is an alpha port of apxs for Win32 for Apache/2.0; grab the script http://perl.apache.org/dist/win32-bin/install_apxs and run it, which will fetch, configure, and install it on your system. beauty. except a) i had to add 'use File::Spec;' to Configure.pl, Sorry about that - I'll fix that. and a 'perl t\TEST -config' blowes up trying to build mod_random_chunk (unresolved symbols _random and _srandom). I noticed that too - I guess it needs linking against some system library; I'll try to find out which one. but it's a whole lot better than before! do things of the form 'open($fh, link foo |);' not work well on windows? because i'm wondering if the giant .bat file could be replaced with a perl script that used that construct to do the linking.. Things like that do work in general, and that's a good idea. I was going to clean the script up (in it's present form it was a hacked port from the unix version), and I'll look at doing something like that. Thanks. -- best regards, randy
Re: testing apache 1.3 on windows
On Mon, 15 Mar 2004, Rodent of Unusual Size wrote: also, there apparently is no longer an apxs.pl for 2.0 windows -- so what's the magic Makefile.PL argument to let the test modules be built? There is an alpha port of apxs for Win32 for Apache/2.0; grab the script http://perl.apache.org/dist/win32-bin/install_apxs and run it, which will fetch, configure, and install it on your system. in case there was any question, i hate development on windows, i hate libtool, and i think i've discovered a special subtype of 'male pattern baldness' -- call it 'hacker pattern baldness,' comes from pulling your hair out. :) -- best regards, randy kobes
Re: testing apache 1.3 on windows
On Mon, 15 Mar 2004, William A. Rowe, Jr. wrote: At 02:51 PM 3/15/2004, you wrote: On Mon, 15 Mar 2004, Rodent of Unusual Size wrote: also, there apparently is no longer an apxs.pl for 2.0 windows -- so what's the magic Makefile.PL argument to let the test modules be built? There is an alpha port of apxs for Win32 for Apache/2.0; grab the script http://perl.apache.org/dist/win32-bin/install_apxs and run it, which will fetch, configure, and install it on your system. Randy ... ready to make a go of integrating into httpd-2.0 build? Bill Sure, Bill - I'd be happy to ... Right now it seems to work OK for external modules (although some cleanup is warranted), but it would need work to be useable within httpd-2.0 itself. -- best regards, randy
Re: Sticky preferences in Windows
On Sat, 13 Mar 2004, William McKee wrote: Hi Stas, I'm running into the sticky preferences problem now as well. I decided the quickest way to get my tests running in the Windows environment would be to install mod_perl. The install notes suggested that the path be c:\apache2 which means the default path of c:\program files\apache2 is no good. I uninstalled apache and reinstalled into c:\. No problems. However, now that I'm trying to rebuild my module to run my tests, the TestConfigParse.pm module is still finding the old path. I've searched my drive manually and with the built-in search tools as well as in the registry but cannot figure out where A::T has squirelled away this setting. Could you give me a pointer? This is WinXP if that makes any difference. I don't think being on Windows makes a difference in this particular case - I think where it gets the info from is C:\Perl\site\lib\Apache\BuildConfig.pm which is generated by Apache::Build. -- best regards, randy kobes
Re: in-place edit in TestRun.pm
On Wed, 10 Mar 2004, Stas Bekman wrote:
Randy Kobes wrote:
Hi,
A recent change in Apache-Test/lib/Apache/TestRun.pm
involves an in-place edit, at around line 765:
[ .. ]
Unfortunately, Win32 can't do such in-place edits:
[ ... ]
why not doing:
local $^I = .bak; # windows can't do inplace edit
local @ARGV = $config_file;
while( ) {
s/old/new/;
print;
}
unlink $config_file.bak;
much simpler.
Very true ... I'll make that change - thanks!
--
best regards,
randy
Re: time for a new A-T release?
On Thu, 19 Feb 2004, Stas Bekman wrote: I'd like to get a new A-T out of the door. There were a *lot* of tweaks and new features added since the last release. It'd be nice to see whether users are happy with them, before we get a new mp2 release out. Hi Stas, Regarding that patch we just discussed about fixing directories with spaces on Win32, I'm away for about a week, but will work on it when I get back. -- best regards, randy
Re: Apache::TestMM::generate_script vs. Win32 Paths
On Tue, 17 Feb 2004, Stas Bekman wrote:
Randy Kobes wrote:
On Tue, 3 Feb 2004, Christopher H. Laco wrote:
I've installed Apache::Test 1.07 on ActiveState perl 5.6.1
build 630 and am trying to make test scripts for a pile of
pages in a package I'm workin on.
If I pass in an -httpd path that has spaces in the path,
it fails.
use ExtUtils::MakeMaker;
use Apache::TestMM qw(test clean);
push @ARGV, '-httpd', 'C:\Program Files\Apache Group\Apache\Apache.exe';
[ .. ]
Is this an Apache::Test problem, or possible an nmake issue?
This case should be handled I'd think on the Apache::Test
side. Does
my $exe = 'C:\Program Files\Apache Group\Apache\Apache.exe';
$exe = Win32::GetShortPathName($exe);
push @ARGV, '-httpd', $exe;
work? If so, I'll look at seeing where this could be added
within Apache::Test.
This patch should probably take care of it. It's untested.
Thanks, Stas - it looks good (applied manually, and
informally tested, as I don't have Perl in a place with
spaces in the directory name). A couple of comments below:
Index: lib/Apache/TestConfig.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm,v
retrieving revision 1.205
diff -u -r1.205 TestConfig.pm
--- lib/Apache/TestConfig.pm 18 Feb 2004 00:30:57 - 1.205
+++ lib/Apache/TestConfig.pm 18 Feb 2004 04:40:21 -
@@ -67,6 +67,16 @@
(map { $_ . '_module_name', $_ module name} qw(cgi ssl thread access
auth)),
);
+my %filepath_conf_opts = map { $_ = 1 }
+qw(top_dir t_dir t_conf t_logs t_conf_file src_dir serverroot
+ documentroot bindir sbindir httpd apxs httpd_conf perlpod sslca
+ libmodperl);
+
+sub conf_opt_is_a_filepath {
+my $opt = shift;
+$opt exists $filepath_conf_opts{$opt};
+}
+
sub usage {
for my $hash (\%Usage) {
for (sort keys %$hash){
Index: lib/Apache/TestRun.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.149
diff -u -r1.149 TestRun.pm
--- lib/Apache/TestRun.pm 18 Feb 2004 04:09:08 - 1.149
+++ lib/Apache/TestRun.pm 18 Feb 2004 04:40:21 -
@@ -238,6 +238,15 @@
push @argv, $val;
}
+# fixup the filepath options on win32 (spaces, short names, etc.)
+if (Apache::TestConfig::WIN32) {
+require Win32::GetShortPathName;
The require isn't required, as Win32::GetShortPathName is
a core function.
+for my $key (keys %conf_opts) {
+next unless Apache::TestConfig::conf_opt_is_a_filepath($key);
+$conf_opts{$key} = Win32::GetShortPathName($conf_opts{$key});
^^^
I think if one calls Win32::GetShortPathName
on something that has no short path name, then
nothing is returned. For example,
==
use strict;
use warnings;
for ('C:\Program Files', 'C:\ProgramFiles') {
my $x = Win32::GetShortPathName($_);
if ($x) {
print $_ has a short name of $x\n;
}
else {
print $_ has no short name\n;
}
}
===
prints
===
C:\Program Files has a short name of C:\PROGRA~1
C:\ProgramFiles has no short name
Thus, the above should probably include
+for my $key (keys %conf_opts) {
+next unless Apache::TestConfig::conf_opt_is_a_filepath($key);
+ + next unless $conf_opts{$key} =~ / /;
+$conf_opts{$key} = Win32::GetShortPathName($conf_opts{$key});
--
best regards,
randy
Re: Apache::TestMM::generate_script vs. Win32 Paths
On Tue, 3 Feb 2004, Christopher H. Laco wrote: I've installed Apache::Test 1.07 on ActiveState perl 5.6.1 build 630 and am trying to make test scripts for a pile of pages in a package I'm workin on. If I pass in an -httpd path that has spaces in the path, it fails. use ExtUtils::MakeMaker; use Apache::TestMM qw(test clean); push @ARGV, '-httpd', 'C:\Program Files\Apache Group\Apache\Apache.exe'; [ .. ] Is this an Apache::Test problem, or possible an nmake issue? This case should be handled I'd think on the Apache::Test side. Does my $exe = 'C:\Program Files\Apache Group\Apache\Apache.exe'; $exe = Win32::GetShortPathName($exe); push @ARGV, '-httpd', $exe; work? If so, I'll look at seeing where this could be added within Apache::Test. -- best regards, randy kobes
Re: sticky preferences in Apache-Test
On Sat, 17 Jan 2004, Stas Bekman wrote: Randy Kobes wrote: [ ... ] I don't have an ~/.apache-test/, and yes, using the perl with the CPAN A-T installed to build the cvs A-T is fine. Where I run into problems in not seeing the configuration dialogue is using the perl with the cvs A-T installed in building the cvs A-T, even if I delete the installed TestConfigData.pm. That's the correct behavior at the moment, because you have mp2 installed. If mp2 is found it has Apache/BuildConfig.pm which tells A-T where httpd is. And A-T will save that value in the global Apache/TestConfigData.pm if it can write to it, or in ~/.apache-test/.' Of course we can change that behavior, but I think it's cool as mp2 users will never see that interactive dialog. That is neat - I was just wondering where A-T was finding this information from. I'd leave that as is - thanks. -- best regards, randy
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestRun.pm
On Sun, 11 Jan 2004, Stas Bekman wrote:
Randy Kobes wrote:
[ ... ]
my Apache is D:\Apache2\bin\Apache.exe, which would
get reported as d:\apache2\bin\apache.exe. If there isn't
an easy way to preserve the case yet still remove such
duplicates, I'll do that - it's not a big deal.
Randy, you are the expert on win32 ;) I have no idea what
method to use to get a consistent case on case-insenstive
file systems. Really I think it's time to extend
File::Spec to handle that and not solve this problem every
time we need to read a filename.
This is an annoyance, for sure ... However, in a sense we
(Apache-Test) have some control over this problem. In
another section we're looking for 'Apache', and then in
TestRun.pm we also look for 'apache'. So both get reported
as being present. However, on Win32, looking for 'apache' is
somewhat misleading, as the default installation (either
binary or source) results in 'Apache'. What about the
following:
Index: lib/Apache/TestRun.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.138
diff -u -r1.138 TestRun.pm
--- lib/Apache/TestRun.pm 11 Jan 2004 15:25:12 - 1.138
+++ lib/Apache/TestRun.pm 13 Jan 2004 14:36:41 -
@@ -1343,11 +1343,13 @@
{
my %choices = ();
+my @tries = Apache::TestConfig::WIN32 ?
+qw(Apache httpd Apache2 httpd2) :
+qw(apache httpd apache2 httpd2);
for (grep defined $_,
map({ catfile $vars-{$_}, $vars-{target} } qw(sbindir bindir)),
$test_config-default_httpd, which($vars-{target}),
- $ENV{APACHE}, which('apache'), which('httpd'),
- $ENV{APACHE2}, which('apache2'), which('httpd2')) {
+ $ENV{APACHE}, $ENV{APACHE2}, map {which($_)} @tries) {
$choices{$_}++ if -e $_ -x _;
}
my $optional = 0;
--
best regards,
randy
Re: sticky preferences in Apache-Test
On Tue, 13 Jan 2004, Stas Bekman wrote: Geoffrey Young wrote: [ ... ] what I do know, however, is that my nightly builds start with 2.1 then move to 2.0, issuing 'make realclean' between each. for the past few nights, the 2.0 tests don't run because it's loading TestConfigData.pm from my global @INC. at that point, TestConfigData.pm is from the last install, which is a 2.1 install. this seems wrong to me - I have no remedy short of removing TestDataConfig.pm between builds - at I think it would affect users that upgrade as well. Are you sure that your not problem is elsewhere? I see this issue too though with non-mp2 build, just didn't have a chance to work on it yet. How do you build your mp2? It should ignore the custom config already, there must be some glitch. I haven't worked through this yet, but I find a similar problem ... I have two Perls, both of which have mp2 installed, but one has the CPAN Apache-Test and the other has the cvs Apache-Test installed. In building the cvs Apache-Test, I get the first-time dialogue with the perl with the CPAN Apache-Test installed, but don't get the dialogue with the perl with the cvs Apache-Test installed. I'm a bit baffled as to why, as this occurs even if I delete the system TestConfigData.pm. -- best regards, randy
Re: sticky preferences in Apache-Test
On Tue, 13 Jan 2004, Stas Bekman wrote: Randy Kobes wrote: I haven't worked through this yet, but I find a similar problem ... I have two Perls, both of which have mp2 installed, but one has the CPAN Apache-Test and the other has the cvs Apache-Test installed. In building the cvs Apache-Test, I get the first-time dialogue with the perl with the CPAN Apache-Test installed, but don't get the dialogue with the perl with the cvs Apache-Test installed. I'm a bit baffled as to why, as this occurs even if I delete the system TestConfigData.pm. But CPAN A-T doesn't have this feature, so you must have installed mp2-cvs on top of it. Also check that you don't have ~/.apache-test/. I don't have an ~/.apache-test/, and yes, using the perl with the CPAN A-T installed to build the cvs A-T is fine. Where I run into problems in not seeing the configuration dialogue is using the perl with the cvs A-T installed in building the cvs A-T, even if I delete the installed TestConfigData.pm. -- best regards, randy
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestRun.pm
On Sat, 10 Jan 2004, Stas Bekman wrote:
[EMAIL PROTECTED] wrote:
randyk 2004/01/10 14:07:17
Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm
TestRun.pm
Log:
On Win32, multiple options for Apache.exe can be returned which differ
only by the case of the .exe extension or by the directory separator.
These changes bring things into line with what is returned from which().
[...]
1.136 +2 -2
httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm
Index: TestRun.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.135
retrieving revision 1.136
diff -u -r1.135 -r1.136
--- TestRun.pm8 Jan 2004 04:54:06 - 1.135
+++ TestRun.pm10 Jan 2004 22:07:17 - 1.136
@@ -1346,8 +1346,8 @@
for (grep defined $_,
map({ catfile $vars-{$_}, $vars-{target} } qw(sbindir
bindir)),
$test_config-default_httpd, which($vars-{target}),
- $ENV{APACHE}, which('apache'), which('httpd'),
- $ENV{APACHE2}, which('apache2'), which('httpd2')) {
+ $ENV{APACHE}, which('Apache'), which('httpd'),
+ $ENV{APACHE2}, which('Apache2'), which('httpd2')) {
$choices{$_}++ if -e $_ -x _;
}
my $optional = 0;
yes, but we need which('apache') too for unix. so please:
- $ENV{APACHE}, which('apache'), which('httpd'),
- $ENV{APACHE2}, which('apache2'), which('httpd2')) {
+ $ENV{APACHE}, which('apache'), which('Apache'),
which('httpd'),
+ $ENV{APACHE2}, which('apache2'), which('Apache2'),
which('httpd2')) {
Sorry about that - I'll revert that change (I just tried,
but got an error message about insufficient space left on a
device). Actually, looking for both 'apache' and 'Apache'
leads back to the same problem on Win32 that, when the list
of Apache binaries is reported, both 'apache' and 'Apache'
are listed (with the same paths), so a different approach is
needed.
--
best regards,
randy
Re: rerunning original_command
On Sat, 10 Jan 2004, Stas Bekman wrote:
Randy Kobes wrote:
Hi,
With the current Apache-Test cvs, after the initial
dialogue asking which Apache binary you want is completed,
the original command is rerun with the desired configuration
options. However, this original command is reproduced as
't/TEST ', and on Win32 't/TEST' isn't recognized as a
command. This diff
===
Index: lib/Apache/TestRun.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.136
diff -u -r1.136 TestRun.pm
--- lib/Apache/TestRun.pm 10 Jan 2004 22:07:17 - 1.136
+++ lib/Apache/TestRun.pm 10 Jan 2004 22:26:57 -
@@ -630,7 +630,7 @@
# reconstruct argv, preserve multiwords args, eg 'PerlTrace all'
my $argv = join , map { /^-/ ? $_ : qq['$_'] } @ARGV;
-$original_command = $0 $argv;
+$original_command = $^X $0 $argv;
$orig_cwd = Cwd::cwd();
$self-set_ulimit;
$self-set_env; #make sure these are always set
=
prepends the Perl binary to this command, which can then
be run.
I'm wondering, though - might there be circumstances where
$original_command contains the Perl binary already?
I think it's pretty safe:
% perl -le 'print $0'
-e
'perl' is not in $0. Is it different on windows?
No, it's the same - I just wanted to be sure that the
Perl binary didn't creep in from somewhere else. Thanks.
--
best regards,
randy
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestRun.pm
On Sun, 11 Jan 2004, Stas Bekman wrote: Randy Kobes wrote: [ .. ] Sorry about that - I'll revert that change (I just tried, but got an error message about insufficient space left on a device). Actually, looking for both 'apache' and 'Apache' leads back to the same problem on Win32 that, when the list of Apache binaries is reported, both 'apache' and 'Apache' are listed (with the same paths), so a different approach is needed. So check that the path and lowercased filename match and exclude those on win32? Yes, that would work, but it looks a bit funny - for example, my Apache is D:\Apache2\bin\Apache.exe, which would get reported as d:\apache2\bin\apache.exe. If there isn't an easy way to preserve the case yet still remove such duplicates, I'll do that - it's not a big deal. -- best regards, randy
Re: win32_fetch_apxs in Apache-Test?
On Sun, 11 Jan 2004, Stas Bekman wrote: Yes, yes, what I was saying is that how the interactive config should know whether it's Apache 1 or Apache 2 that the user is after? or did you want to suggest it after user has specified the value for httpd and then if you figure out that it's for Apache2 and there is no apxs, you'd suggest to install it? I think that sounds like a working solution. Yes, the latter is what I was thinking - I'll make up something for that and pass it along. Thanks. -- best regards, randy
rerunning original_command
Hi,
With the current Apache-Test cvs, after the initial
dialogue asking which Apache binary you want is completed,
the original command is rerun with the desired configuration
options. However, this original command is reproduced as
't/TEST ', and on Win32 't/TEST' isn't recognized as a
command. This diff
===
Index: lib/Apache/TestRun.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.136
diff -u -r1.136 TestRun.pm
--- lib/Apache/TestRun.pm 10 Jan 2004 22:07:17 - 1.136
+++ lib/Apache/TestRun.pm 10 Jan 2004 22:26:57 -
@@ -630,7 +630,7 @@
# reconstruct argv, preserve multiwords args, eg 'PerlTrace all'
my $argv = join , map { /^-/ ? $_ : qq['$_'] } @ARGV;
-$original_command = $0 $argv;
+$original_command = $^X $0 $argv;
$orig_cwd = Cwd::cwd();
$self-set_ulimit;
$self-set_env; #make sure these are always set
=
prepends the Perl binary to this command, which can then
be run.
I'm wondering, though - might there be circumstances where
$original_command contains the Perl binary already?
--
best regards,
randy
win32_fetch_apxs in Apache-Test?
Hi, The current Apache-Test cvs, as well as looking for an Apache binary, will also search for apxs, which doesn't come with Apache-2 on Win32. Within the mod_perl 2 distribution Makefile.PL will offer to run a script on Win32 to fetch and install an apxs - might it be an idea to do the same for Apache-Test, or perhaps within the perl-framework Makefile.PL? -- best regards, randy
Re: sticky preferences in Apache-Test
On Wed, 24 Sep 2003, Randy Kobes wrote:
Hi,
Below is a modified diff to allow for preferences
to be saved to an Apache::TestConfigData for later use
within Apache::Test. In this version, a user can create
a $HOME/.apache-test/Apache/TestConfigData.pm to specify
the preferences; this will be used, if it exists, before
a system Apache::TestConfigData. The diff is applied
against the cvs Apache-Test sources; as well, an
empty Apache-Test/lib/Apache/TestConfigData.pm file
should be created:
===
package Apache::TestConfigData;
use strict;
use warnings;
use vars qw($vars);
$vars = {
};
1;
=head1 NAME
Apache::TestConfigData - Configuration file for Apache::Test
=cut
The intent of how this is supposed to work is in the pod
of Apache::TestRun.
Sorry - I forgot to include the diff to Apache::TestUtil -
a complete diff appears below.
Index: lib/Apache/TestRun.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.114
diff -u -r1.114 TestRun.pm
--- lib/Apache/TestRun.pm 12 Sep 2003 02:21:32 - 1.114
+++ lib/Apache/TestRun.pm 25 Sep 2003 06:25:56 -
@@ -10,20 +10,24 @@
use Apache::TestRequest ();
use Apache::TestHarness ();
use Apache::TestTrace;
+use Apache::TestUtil qw(expand_path);
+use Cwd;
use File::Find qw(finddepth);
-use File::Spec::Functions qw(catfile);
+use File::Spec::Functions qw(catfile catdir);
use Getopt::Long qw(GetOptions);
+use File::Basename qw(dirname);
use Config;
use constant STARTUP_TIMEOUT = 300; # secs (good for extreme debug cases)
+
use subs qw(exit_shell exit_perl);
my %core_files = ();
my %original_t_perms = ();
my @std_run = qw(start-httpd run-tests stop-httpd);
-my @others = qw(verbose configure clean help ssl http11);
+my @others = qw(verbose configure clean help ssl http11 save);
my @flag_opts= (@std_run, @others);
my @string_opts = qw(order trace);
my @ostring_opts = qw(proxy ping);
@@ -55,9 +59,22 @@
'ssl' = 'run tests through ssl',
'proxy' = 'proxy requests (default proxy is localhost)',
'trace=T' = 'change tracing default to: warning, notice, info,
debug, ...',
+ 'save'= 'save test paramaters into Apache::TestConfigData',
(map { $_, \U$_\E url } @request_opts),
);
+# variables stored in $Apache::TestConfigData::vars
+my @data_vars = qw(httpd port user group apxs);
+# mapping from $Apache::TestConfigData::vars to $ENV settings
+my %vars_to_env = (httpd = 'APACHE',
+ user = 'APACHE_USER',
+ group = 'APACHE_GROUP',
+ apxs = 'APXS',
+ port = 'APACHE_PORT',
+ );
+my $IN_APACHE_TEST = in_apache_test();
+my $CONFIG_DATA = config_data();
+
sub fixup {
#make sure we use an absolute path to perl
#else Test::Harness uses the perl in our PATH
@@ -407,6 +424,8 @@
$test_config-cmodules_configure;
$test_config-generate_httpd_conf;
$test_config-save;
+$self-write_config() if
+($IN_APACHE_TEST or $self-{opts}-{save});
}
sub try_exit_opts {
@@ -509,6 +528,10 @@
sub new_test_config {
my $self = shift;
+for (@data_vars) {
+next unless $Apache::TestConfigData::vars-{$_};
+$self-{conf_opts}-{$_} ||= $Apache::TestConfigData::vars-{$_};
+}
Apache::TestConfig-new($self-{conf_opts});
}
@@ -953,6 +976,102 @@
CORE::exit $_[0];
}
+# Are we building things within Apache-Test?
+sub in_apache_test {
+my $cwd = expand_path(cwd);
+return ($cwd =~ m{Apache-Test}) ? 1 : 0;
+}
+
+# routine to determine where the configuration file
+# Apache::TestConfigData lives. The order searched is
+# 1) a path within Apache-Test, if we are building things there
+# 2) an $ENV{HOME}/.apache-test/ directory;
+# 3) somewhere in @INC, other than a path within Apache-Test.
+sub config_data {
+my $config;
+my $file = 'TestConfigData.pm';
+# XXX $ENV{HOME} isn't propagated in mod_perl
+unshift @INC, catdir($ENV{HOME}, '.apache-test') if $ENV{HOME};
+for (@INC) {
+my $candidate = catfile($_, 'Apache', $file);
+if (-e $candidate) {
+eval {require $candidate};
+next if $@;
+if (config_has_data()) {
+$config = $candidate;
+last;
+}
+}
+}
+unless ($IN_APACHE_TEST) {
+die 'Could not find a valid Apache::TestConfigData'
+unless config_has_data();
+}
+shift @INC if $ENV{HOME};
+# preferentially use environment variables
+for (@data_vars) {
+next unless my $value = $ENV{$vars_to_env{$_}};
+$Apache::TestConfigData
sticky preferences in Apache-Test
Hi,
Below is a modified diff to allow for preferences
to be saved to an Apache::TestConfigData for later use
within Apache::Test. In this version, a user can create
a $HOME/.apache-test/Apache/TestConfigData.pm to specify
the preferences; this will be used, if it exists, before
a system Apache::TestConfigData. The diff is applied
against the cvs Apache-Test sources; as well, an
empty Apache-Test/lib/Apache/TestConfigData.pm file
should be created:
===
package Apache::TestConfigData;
use strict;
use warnings;
use vars qw($vars);
$vars = {
};
1;
=head1 NAME
Apache::TestConfigData - Configuration file for Apache::Test
=cut
The intent of how this is supposed to work is in the pod
of Apache::TestRun.
===
Index: lib/Apache/TestRun.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.114
diff -u -r1.114 TestRun.pm
--- lib/Apache/TestRun.pm 12 Sep 2003 02:21:32 - 1.114
+++ lib/Apache/TestRun.pm 24 Sep 2003 21:52:08 -
@@ -10,20 +10,24 @@
use Apache::TestRequest ();
use Apache::TestHarness ();
use Apache::TestTrace;
+use Apache::TestUtil qw(expand_path);
+use Cwd;
use File::Find qw(finddepth);
-use File::Spec::Functions qw(catfile);
+use File::Spec::Functions qw(catfile catdir);
use Getopt::Long qw(GetOptions);
+use File::Basename qw(dirname);
use Config;
use constant STARTUP_TIMEOUT = 300; # secs (good for extreme debug cases)
+
use subs qw(exit_shell exit_perl);
my %core_files = ();
my %original_t_perms = ();
my @std_run = qw(start-httpd run-tests stop-httpd);
-my @others = qw(verbose configure clean help ssl http11);
+my @others = qw(verbose configure clean help ssl http11 save);
my @flag_opts= (@std_run, @others);
my @string_opts = qw(order trace);
my @ostring_opts = qw(proxy ping);
@@ -55,9 +59,22 @@
'ssl' = 'run tests through ssl',
'proxy' = 'proxy requests (default proxy is localhost)',
'trace=T' = 'change tracing default to: warning, notice, info,
debug, ...',
+ 'save'= 'save test paramaters into Apache::TestConfigData',
(map { $_, \U$_\E url } @request_opts),
);
+# variables stored in $Apache::TestConfigData::vars
+my @data_vars = qw(httpd port user group apxs);
+# mapping from $Apache::TestConfigData::vars to $ENV settings
+my %vars_to_env = (httpd = 'APACHE',
+ user = 'APACHE_USER',
+ group = 'APACHE_GROUP',
+ apxs = 'APXS',
+ port = 'APACHE_PORT',
+ );
+my $IN_APACHE_TEST = in_apache_test();
+my $CONFIG_DATA = config_data();
+
sub fixup {
#make sure we use an absolute path to perl
#else Test::Harness uses the perl in our PATH
@@ -407,6 +424,8 @@
$test_config-cmodules_configure;
$test_config-generate_httpd_conf;
$test_config-save;
+$self-write_config() if
+($IN_APACHE_TEST or $self-{opts}-{save});
}
sub try_exit_opts {
@@ -509,6 +528,10 @@
sub new_test_config {
my $self = shift;
+for (@data_vars) {
+next unless $Apache::TestConfigData::vars-{$_};
+$self-{conf_opts}-{$_} ||= $Apache::TestConfigData::vars-{$_};
+}
Apache::TestConfig-new($self-{conf_opts});
}
@@ -953,6 +976,102 @@
CORE::exit $_[0];
}
+# Are we building things within Apache-Test?
+sub in_apache_test {
+my $cwd = expand_path(cwd);
+return ($cwd =~ m{Apache-Test}) ? 1 : 0;
+}
+
+# routine to determine where the configuration file
+# Apache::TestConfigData lives. The order searched is
+# 1) a path within Apache-Test, if we are building things there
+# 2) an $ENV{HOME}/.apache-test/ directory;
+# 3) somewhere in @INC, other than a path within Apache-Test.
+sub config_data {
+my $config;
+my $file = 'TestConfigData.pm';
+# XXX $ENV{HOME} isn't propagated in mod_perl
+unshift @INC, catdir($ENV{HOME}, '.apache-test') if $ENV{HOME};
+for (@INC) {
+my $candidate = catfile($_, 'Apache', $file);
+if (-e $candidate) {
+eval {require $candidate};
+next if $@;
+if (config_has_data()) {
+$config = $candidate;
+last;
+}
+}
+}
+unless ($IN_APACHE_TEST) {
+die 'Could not find a valid Apache::TestConfigData'
+unless config_has_data();
+}
+shift @INC if $ENV{HOME};
+# preferentially use environment variables
+for (@data_vars) {
+next unless my $value = $ENV{$vars_to_env{$_}};
+$Apache::TestConfigData::vars-{$_} = $value;
+}
+
+return $config;
+}
+
+sub config_has_data {
+return ($Apache::TestConfigData::vars and
+
Re: need help to add per-user config to Apache::Test
On Sat, 6 Sep 2003, Stas Bekman wrote:
Randy Kobes wrote:
On Thu, 4 Sep 2003, Stas Bekman wrote:
In the effort to remove some of the Win32 noise, I was
thinking that we can write a generic function which gets a
path as an argument and figures out internally if it needs
to keep the argument as passed or mangle it. So it'll do
something like:
my $cwd = Apache::TestUtil::path(cwd);
probably need a more intuitive name for this function.
That'd be nice - a version that does this appears below.
I named it win32_long_path - it'll just return what was
passed into it if not on Win32.
But my idea was to eliminate any os-specific words win32. I think it should
just be long_path... Think of it as File::Spec function.
OK, I'll do that. I put in the win32_ to indicate that it'll
do something for Win32, and otherwise just return what was
passed in.
I'm still not quite happy about the naming of the function, what exactly
GetLongPathName($file) does?
can this be done using some File::Spec function?
I haven't found an equivalent one in File::Spec ... The
problem here is that cwd (or any file/directory name) on
Win32 has two representations - a long path name (that can
include spaces) and a short path name, limited to 6
characters (this is a holdout from early days), plus 3 if an
extension is present. Here we want to match cwd to
/Apache-Test/, but cwd may return the short path name (eg,
Apache~1.0), depending on if, for example, you have
different Apache-Test* directories at the same level. So
GetLongPathName can be used to get the full long path name.
The thing with naming it, eg, just long_path, is that
Unix users (the majority) wouldn't know what it does.
+require File::Spec;
+my $candidate = File::Spec-catfile($_, 'Apache', $file);
we import catfile in all other Apache::Test files, can do
that here as well... will make code simpler
Good point - thanks.
+if (-e $candidate) {
+$sys_config = $candidate;
+last;
+}
+}
+if ($sys_config) {
+eval {require $sys_config};
+return $sys_config if (not $@ and IN_APACHE_TEST);
+$sys_config = undef if $@;
+}
Hmm, I thought we agreed that eval {require $sys_config} will always succeed,
since that file is always available. so this code should be needed:
+ die 'Could not find a suitable Apache::TestConfigData'
+unless defined CONFIG_DATA;
I was thinking here if someone, after installation, had
mis-edited Apache::TestConfigData, either the system one or
one found in some path in @INC being added thru, eg, use
lib). But this might be overkill - not worrying about this
at this time will simplify things here.
One more problem is TestRun.pm's layout: subs should go
after the declarations (uses/constants/etc). use 'use
subs' if you need to predeclare them.
OK - thanks.
Another issue, is in_apache_test. Since a user may get it
with modperl-2.0 or separately it should return true in
either case.
I forgot about that - thanks.
+sub write_config {
+my $self = shift;
+my $fh = Symbol::gensym();
+my $vars = $self-{test_config}-{vars};
+my $conf_opts = $self-{conf_opts};
+my $file = IN_APACHE_TEST ?
+catfile($vars-{top_dir}, CONFIG_DATA) :
+CONFIG_DATA;
it's easier to parse when written as:
my $file = IN_APACHE_TEST
? catfile($vars-{top_dir}, CONFIG_DATA)
: CONFIG_DATA;
+my $pkg = EOC;
+package Apache::TestConfigData;
better have it strict, to avoid misterious errors (same in the pod below)
use strict;
use warnings;
use vars (\$Apache::TestConfigData);
Thanks - I'll add that.
I was also thinking about the problem of $ENV{HOME} not
being available in mod_perl. As Apache::TestConfigData is
being loaded in order to configure things, shouldn't
this not be a problem, because at this point one isn't
yet in a mod_perl environment?
--
best regards,
randy
Re: need help to add per-user config to Apache::Test
On Wed, 3 Sep 2003, Stas Bekman wrote:
Randy Kobes wrote:
On Tue, 2 Sep 2003, Stas Bekman wrote:
[ .. ]
It should work during 'make test' as well, since it already runs t/TEST
-config. And also whenever you provide any options to t/TEST it reconfigures,
so I believe the normal run will do the same:
t/TEST -save -httpd /usr/local/httpd/bin/httpd
I haven't tested that though.
I've checked that (with the diff below), and it seems to
work now as you say, both within Apache-Test and for a 3rd
party package. Without the -save the new -httpd is used,
but not saved into Apache::TestConfigData.
[ .. ]
Good idea - that's much simpler. The following assumes
that an empty Apache/TestConfigData.pm is present, and
then, as you say, 'make install' will pick up any changes
that have been made to it.
If I remember correctly 'make install' will complain about
the mismatch in sizes since 'make' has already put the
files into blib? Did it work for you just fine? Purhaps we
do need to update the two.
On linux, I tried installing Apache-Test, and then changing
the settings via
t/TEST -save -httpd /path/to/some/other/httpd
This wrote a new lib/Apache/TestConfigData.pm, and
make install
did recognize the change, copied it over to blib/, and
installed the new copy.
The diff below also includes a change to better get the
location of Apache::TestConfigData.
==
Index: lib/Apache/TestRun.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.113
diff -u -r1.113 TestRun.pm
--- lib/Apache/TestRun.pm 22 Jul 2003 11:21:36 - 1.113
+++ lib/Apache/TestRun.pm 4 Sep 2003 21:02:44 -
@@ -11,19 +11,69 @@
use Apache::TestHarness ();
use Apache::TestTrace;
+use constant WIN32 = Apache::TestConfig::WIN32;
+require Win32 if WIN32;
+
+use Cwd;
+# Are we building things within Apache-Test?
+sub in_apache_test {
+my $cwd = WIN32 ? Win32::GetLongPathName(cwd) : cwd;
+return ($cwd =~ m{Apache-Test}) ? 1 : 0;
+}
+use constant IN_APACHE_TEST = in_apache_test();
+
+require File::Spec;
+# routine to determine where the configuration file
+# Apache::TestConfigData lives. The order searched is
+# 1) a path within Apache-Test, if we are building things there
+# 2) an $ENV{HOME}/.apache-test/ directory;
+# 3) somewhere in @INC, other than a path within Apache-Test.
+sub config_data {
+my $sys_config;
+my $file = 'TestConfigData.pm';
+for (@INC) {
+ my $candidate = File::Spec-catfile($_, 'Apache', $file);
+ if (-e $candidate) {
+ $sys_config = $candidate;
+ last;
+ }
+}
+if ($sys_config) {
+ eval {require $sys_config};
+ return $sys_config if (not $@ and IN_APACHE_TEST);
+ $sys_config = undef if $@;
+}
+# XXX $ENV{HOME} isn't propagated in mod_perl
+if ($ENV{HOME}) {
+ my $priv_config = File::Spec-catfile($ENV{HOME},
+ '.apache-test',
+ $file);
+eval {require $priv_config};
+ return $priv_config unless $@;
+}
+return $sys_config ? $sys_config : undef;
+}
+
+use constant CONFIG_DATA = config_data();
+
use File::Find qw(finddepth);
-use File::Spec::Functions qw(catfile);
+use File::Spec::Functions qw(catfile catdir);
use Getopt::Long qw(GetOptions);
+use File::Basename;
use Config;
+use Symbol;
use constant STARTUP_TIMEOUT = 300; # secs (good for extreme debug cases)
use subs qw(exit_shell exit_perl);
+die 'Could not find a suitable Apache::TestConfigData'
+unless defined CONFIG_DATA;
+
my %core_files = ();
my %original_t_perms = ();
my @std_run = qw(start-httpd run-tests stop-httpd);
-my @others = qw(verbose configure clean help ssl http11);
+my @others = qw(verbose configure clean help ssl http11 save);
my @flag_opts= (@std_run, @others);
my @string_opts = qw(order trace);
my @ostring_opts = qw(proxy ping);
@@ -55,6 +105,7 @@
'ssl' = 'run tests through ssl',
'proxy' = 'proxy requests (default proxy is localhost)',
'trace=T' = 'change tracing default to: warning, notice, info,
debug, ...',
+ 'save'= 'save test paramaters into Apache::TestConfigData',
(map { $_, \U$_\E url } @request_opts),
);
@@ -407,6 +458,8 @@
$test_config-cmodules_configure;
$test_config-generate_httpd_conf;
$test_config-save;
+$self-write_config() if
+(not %{$Apache::TestConfigData} or $self-{opts}-{save});
}
sub try_exit_opts {
@@ -509,6 +562,10 @@
sub new_test_config {
my $self = shift;
+for (qw(httpd port user group apxs)) {
+next unless $Apache::TestConfigData-{$_};
+$self-{conf_opts}-{$_} ||= $Apache::TestConfigData-{$_};
+}
Apache::TestConfig-new($self-{conf_opts
Re: need help to add per-user config to Apache::Test
On Tue, 2 Sep 2003, Stas Bekman wrote:
Randy Kobes wrote:
[ .. ]
Very good, a few more comments following
===
Index: TestRun.pm
[...]
+$self-write_config() if
probably better to do that right after $self-configure is
completed, as the very last thing in:
Apache::TestRun::configure
OK - this is done in the diff at the end. For this, to
override a setting within Apache::TestConfigData from some
external package, one has to do
t/TEST -config -save -httpd /usr/local/httpd/bin/httpd
[...]
+use Symbol qw(gensym);
[...]
+my $fh = Symbol::gensym();
then probably don't need to import it.
Right - thanks.
+my $file = catfile($dir, 'TestConfigData.pm');
+unless (open($fh, $file)) {
+warn Cannot open $file: $!;
+return;
+}
[ .. ]
Ahm, so you write that file twice if inside the
Apache-Test build dir because Makefile.PL has been run
long time ago. We will have problems with MakeMaker
picking this file for 'make install', so we must provide a
placeholder for that file. I suppose
Apache/TestConfigData.pm always needs to be in the
distribution but include an empty:
$Apache::TestConfigData = {};
So now instead of trying to eval {} for the module in @_
we can simply require it, and then test whether
%$Apache::TestConfigData has something in it?
Good idea - that's much simpler. The following assumes
that an empty Apache/TestConfigData.pm is present, and
then, as you say, 'make install' will pick up any changes
that have been made to it.
===
Index: lib/Apache/TestRun.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.113
diff -u -r1.113 TestRun.pm
--- lib/Apache/TestRun.pm 22 Jul 2003 11:21:36 - 1.113
+++ lib/Apache/TestRun.pm 3 Sep 2003 06:56:29 -
@@ -11,10 +11,54 @@
use Apache::TestHarness ();
use Apache::TestTrace;
+use constant WIN32 = Apache::TestConfig::WIN32;
+require Win32 if WIN32;
+
+use Cwd;
+# Are we building things within Apache-Test?
+sub in_apache_test {
+my $cwd = WIN32 ? Win32::GetLongPathName(cwd) : cwd;
+return ($cwd =~ m{Apache-Test}) ? 1 : 0;
+}
+use constant IN_APACHE_TEST = in_apache_test();
+
+require File::Spec;
+# routine to determine where the configuration file
+# Apache::TestConfigData lives. The order searched is
+# 1) a path within Apache-Test, if we are building things there
+# 2) an $ENV{HOME}/.apache-test/ directory;
+# 3) somewhere in @INC, other than a path within Apache-Test.
+sub config_data {
+my $config;
+my $file = 'TestConfigData.pm';
+for (@INC) {
+ my $candidate = File::Spec-catfile($_, 'Apache', $file);
+ if (-e $candidate) {
+ $config = $candidate;
+ last;
+ }
+}
+eval {require $config};
+return $config if (not $@ and IN_APACHE_TEST);
+# XXX $HOME isn't propagated in mod_perl
+if ($ENV{HOME}) {
+ $config = File::Spec-catfile($ENV{HOME},
+ '.apache-test',
+ $file);
+eval {require $config};
+ return $config unless $@;
+}
+return $@ ? undef : $config;
+}
+
+use constant CONFIG_DATA = config_data();
+
use File::Find qw(finddepth);
-use File::Spec::Functions qw(catfile);
+use File::Spec::Functions qw(catfile catdir);
use Getopt::Long qw(GetOptions);
+use File::Basename;
use Config;
+use Symbol;
use constant STARTUP_TIMEOUT = 300; # secs (good for extreme debug cases)
use subs qw(exit_shell exit_perl);
@@ -23,7 +67,7 @@
my %original_t_perms = ();
my @std_run = qw(start-httpd run-tests stop-httpd);
-my @others = qw(verbose configure clean help ssl http11);
+my @others = qw(verbose configure clean help ssl http11 save);
my @flag_opts= (@std_run, @others);
my @string_opts = qw(order trace);
my @ostring_opts = qw(proxy ping);
@@ -55,6 +99,7 @@
'ssl' = 'run tests through ssl',
'proxy' = 'proxy requests (default proxy is localhost)',
'trace=T' = 'change tracing default to: warning, notice, info,
debug, ...',
+ 'save'= 'save test paramaters into Apache::TestConfigData',
(map { $_, \U$_\E url } @request_opts),
);
@@ -407,6 +452,8 @@
$test_config-cmodules_configure;
$test_config-generate_httpd_conf;
$test_config-save;
+$self-write_config() if
+(IN_APACHE_TEST or $self-{opts}-{save});
}
sub try_exit_opts {
@@ -509,6 +556,10 @@
sub new_test_config {
my $self = shift;
+for (qw(httpd port user group apxs)) {
+next unless $Apache::TestConfigData-{$_};
+$self-{conf_opts}-{$_} ||= $Apache::TestConfigData-{$_};
+}
Apache::TestConfig-new($self-{conf_opts});
}
@@ -614,6 +665,7 @@
$self-run_tests;
$self
Re: need help to add per-user config to Apache::Test
On Tue, 2 Sep 2003, Stas Bekman wrote:
Randy Kobes wrote:
[ ... ]
sub filter_args {
my($args, $wanted_args) = @_;
+if (HAS_CONFIG) {
+for (qw(group user apxs port httpd)) {
+next unless defined $Apache::MyTestConfig-{$_};
+unshift @$args, -$_, $Apache::MyTestConfig-{$_};
+}
+}
may be it's better to do it at a later stage? this just
used to generate t/TEST and similar scripts. If MyConfig
has changed since t/TEST was generated the changes won't
affect t/TEST.
[ .. ]
Thanks, Stas. You're right about the problems with $HOME,
and I'll take a more careful look at it, as well as your
other comments. In the meantime, here's something that
inserts the data at a later stage, and yet still can get
overridden by explicit arguments to t/TEST. In this
attempt, all the changes are made to Apache::TestRun.pm.
===
Index: TestRun.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.113
diff -u -r1.113 TestRun.pm
--- TestRun.pm 22 Jul 2003 11:21:36 - 1.113
+++ TestRun.pm 2 Sep 2003 22:31:40 -
@@ -11,10 +11,31 @@
use Apache::TestHarness ();
use Apache::TestTrace;
+require File::Spec;
+sub has_config {
+my $has_config = 0;
+# XXX $HOME isn't propagated in mod_perl
+if ($ENV{HOME}) {
+eval
+{require File::Spec-catfile($ENV{HOME},
+ '.apache-test',
+'TestConfigData.pm');};
+$has_config = 1 unless $@;
+}
+unless ($has_config) {
+eval {require Apache::TestConfigData;};
+$has_config = 1 unless $@;
+}
+return $has_config;
+}
+use constant HAS_CONFIG = has_config();
+
use File::Find qw(finddepth);
-use File::Spec::Functions qw(catfile);
+use File::Spec::Functions qw(catfile catdir);
use Getopt::Long qw(GetOptions);
+use File::Basename;
use Config;
+use Symbol qw(gensym);
use constant STARTUP_TIMEOUT = 300; # secs (good for extreme debug cases)
use subs qw(exit_shell exit_perl);
@@ -23,7 +44,7 @@
my %original_t_perms = ();
my @std_run = qw(start-httpd run-tests stop-httpd);
-my @others = qw(verbose configure clean help ssl http11);
+my @others = qw(verbose configure clean help ssl http11 save);
my @flag_opts= (@std_run, @others);
my @string_opts = qw(order trace);
my @ostring_opts = qw(proxy ping);
@@ -55,6 +76,7 @@
'ssl' = 'run tests through ssl',
'proxy' = 'proxy requests (default proxy is localhost)',
'trace=T' = 'change tracing default to: warning, notice, info,
debug, ...',
+ 'save'= 'save test paramaters into Apache::TestConfigData',
(map { $_, \U$_\E url } @request_opts),
);
@@ -509,6 +531,12 @@
sub new_test_config {
my $self = shift;
+if (HAS_CONFIG) {
+for (qw(httpd port user group apxs)) {
+next unless $Apache::TestConfigData-{$_};
+ $self-{conf_opts}-{$_} ||= $Apache::TestConfigData-{$_};
+}
+}
Apache::TestConfig-new($self-{conf_opts});
}
@@ -614,6 +642,10 @@
$self-run_tests;
$self-stop;
+
+$self-write_config() if
+($self-{opts}-{save} or not HAS_CONFIG);
+
}
my @oh = qw(jeez golly gosh darn shucks dangit rats nuts dangnabit crap);
@@ -915,6 +947,75 @@
#require Carp;
#Carp::cluck('exiting');
CORE::exit $_[0];
+}
+
+sub write_config {
+my $self = shift;
+my $dir;
+for (@INC) {
+my $candidate = catfile($_, 'Apache', 'Test.pm');
+if (-e $candidate) {
+$dir = dirname($candidate);
+last;
+}
+}
+unless (-w $dir) {
+$dir = catdir($ENV{HOME}, '.apache-test');
+unless (-d $dir) {
+mkdir $dir or do {
+warn Cannot mkdir $dir: $!;
+return;
+};
+}
+}
+
+my $fh = Symbol::gensym();
+my $file = catfile($dir, 'TestConfigData.pm');
+unless (open($fh, $file)) {
+warn Cannot open $file: $!;
+return;
+}
+warn Writing $file \n;
+my $vars = $self-{test_config}-{vars};
+my $config_dump;
+for (qw(group user apxs port httpd)) {
+next unless $vars-{$_};
+$config_dump .= qq{'$_' = } . qq{'$vars-{$_}',\n};
+}
+
+my $pkg = EOC;
+package Apache::TestConfigData;
+\$Apache::TestConfigData = {
+$config_dump
+};
+1;
+
+=head1 NAME
+
+Apache::TestConfigData - Configuration file for Apache::Test
+
+=cut
+EOC
+print $fh $pkg;
+close $fh;
+my $test = catdir($vars-{top_dir}, 'blib/lib/Apache');
+if (-e catfile($test, 'Test.pm')) {
+my $fh = Symbol::gensym();
+my $file = catfile($test, 'TestConfigData.pm');
+if (-e $file) {
+unlink $file or do {
+warn
Re: need help to add per-user config to Apache::Test
On Thu, 28 Aug 2003, Stas Bekman wrote: Several people have asked for having a new feature in Apache::Test: they want to configure it once (where the server, apxs, etx are) and run Apache::Test without needing to pass any arguments. Matt suggested that it should remember the values passed the first time it's used and then re-use them. However on a system with several users and different preferences, this won't work. Therefore we need to be able to support per-user preferences. CPAN.pm's setup seems to provide a good solution to the same problem (CPAN/Config.pm and ~user/.cpan/CPAN/Config.pm). So I thought that someone would like to port the functionality from CPAN.pm to Apache::Test and send the patches here. It's all pure perl, so you have no excuses that it's XS/C ;) I have a mostly functional version of this, save for the ability to use a $HOME/.apache-test/Config.pm, which shouldn't be too hard to add. I'll try to finish it off this weekend. -- best regards, randy kobes
Re: apxs on Win32
On Tue, 29 Jul 2003, Stas Bekman wrote:
Randy Kobes wrote:
[...]
I'll take a look at this tonight as well - it'd probably
be easier to change, for Win32, the assumption of the
name of the httpd binary when apxs is present.
Thanks Randy!
Thanks for looking this over, Stas - I know you're really busy
right now ... I've attached a diff incorporating the earlier
suggestions - this one also has an additional fix to adjust the
file names to be cleaned on Win32, which are different.
As far getting the right name for the Win32 binary goes with apxs
present, I don't think there's an ideal solution ... To
summarize, the problem is that apxs -q TARGET ( = httpd) is used
in Apache-Test for the name of the apache binary, whereas in
other places (in apxs itself, for example) it's used to represent
httpd.conf. What I ended up doing here is following the
Apache-Test convention of setting $vars-{target} to Apache.exe
for Win32 - this means overwriting the apxs value, which isn't
great, but I guess as long as the same convention is followed
throughout the package, it should be OK.
--
best regards,
randy? s.diff
? s.txt
Index: TestConfig.pm
===
RCS file:
/home/cvspublic/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm,v
retrieving revision 1.166
diff -u -r1.166 TestConfig.pm
--- TestConfig.pm 29 Jul 2003 15:19:24 - 1.166
+++ TestConfig.pm 30 Jul 2003 02:50:32 -
@@ -283,7 +283,7 @@
$self-{APXS} = $self-default_apxs;
return unless $self-{APXS};
-
+$self-{APXS} =~ s {/}{\\}g if WIN32;
my $vars = $self-{vars};
$vars-{bindir} ||= $self-apxs('BINDIR', 1);
@@ -300,7 +300,8 @@
my $self = shift;
my $vars = $self-{vars};
-$vars-{target} ||= (WIN32 ? 'Apache.exe' : 'httpd');
+$vars-{target} ||= 'httpd';
+$vars-{target} = 'Apache.exe' if WIN32;
unless ($vars-{httpd}) {
#sbindir should be bin/ with the default layout
Index: TestConfigC.pm
===
RCS file:
/home/cvspublic/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfigC.pm,v
retrieving revision 1.20
diff -u -r1.20 TestConfigC.pm
--- TestConfigC.pm 31 Mar 2003 06:58:40 - 1.20
+++ TestConfigC.pm 30 Jul 2003 02:50:32 -
@@ -9,6 +9,8 @@
use Apache::TestTrace;
use File::Find qw(finddepth);
+use constant WIN32 = Apache::TestConfig::WIN32;
+
sub cmodule_find {
my($self, $mod) = @_;
@@ -76,7 +78,7 @@
EOF
}
-my %lib_dir = (1 = , 2 = .libs/);
+my %lib_dir = WIN32 ? (1 = , 2 = ) : (1 = , 2 = .libs/);
sub cmodules_build_so {
my($self, $name) = @_;
@@ -135,6 +137,11 @@
my $lib = $self-cmodules_build_so($name);
+my $extras = WIN32 ? ' -llibhttpd -p ' : '';
+my $rm = WIN32 ? '@erase' : 'rm -rf';
+my $goners = join ' ', ( map {$name . '.' . $_}
+(WIN32 ? qw(exp lib so lo) : qw(o lo slo la)) );
+
my $fh = Symbol::gensym();
open $fh, $makefile or die open $makefile: $!;
@@ -143,10 +150,10 @@
all: $lib
$lib: $name.c
- \$(APXS) $dversion -I$self-{cmodules_dir} -c $name.c
+ \$(APXS) $dversion -I$self-{cmodules_dir} $extras -c $name.c
clean:
- -rm -rf $name.o $name.lo $name.slo $name.la .libs
+ -$rm $goners .libs
EOF
close $fh or die close $makefile: $!;
Re: apxs on Win32
On Tue, 29 Jul 2003, Stas Bekman wrote:
Randy Kobes wrote:
On Tue, 29 Jul 2003, Stas Bekman wrote:
Randy Kobes wrote:
I've been looking at getting apxs for Win32 working on Apache 2.
where would it go? Apache::Test? mod_perl?
If there's consensus, I think the better place would be
Apache-Test, as it can be used outside of mod_perl. If so,
I'll clean things up a bit, and put up a new version; I
could also generate something for Apache-Test's Makefile.PL
to have it configure and install this on Win32, if wanted.
+1
Here's a diff to do this for the top-level Apache-Test
Makefile.PL:
Index: Makefile.PL
===
RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/Makefile.PL,v
retrieving revision 1.13
diff -u -r1.13 Makefile.PL
--- Makefile.PL 18 Jun 2003 08:55:57 - 1.13
+++ Makefile.PL 30 Jul 2003 04:56:53 -
@@ -10,6 +10,8 @@
# Makefile.PL, top-level sets this env var
use constant TOP_LEVEL = !exists $ENV{MOD_PERL_2_BUILD};
+use constant WIN32 = $^O =~ /Win32/;
+
use ExtUtils::MakeMaker;
use Symbol;
@@ -26,6 +28,8 @@
Apache::TestMM::generate_script($_);
}
+ask_about_apxs() if WIN32;
+
set_version();
# if built with mod_perl 2.0, it top-level Makefile.PL already
@@ -97,4 +101,24 @@
$string;
};
+}
+
+sub ask_about_apxs {
+print 'END';
+
+I see you're on Win32. If you use Apache 2, I can install a
+version of apxs, which is a tool that automates many of the
+steps to build Apache C modules, if you like. Just answer 'yes'
+at the prompt below.
+
+END
+my $ans = prompt('Install apxs?', 'yes');
+if ($ans =~ /^y/i) {
+my $file = 'apxs_win32_PL';
+unless (my $return = do $file) {
+warn Couldn't parse $file: $@ if $@;
+warn Couldn't do $file: $! unless defined $return;
+warn Couldn't run $fileunless $return;
+}
+}
}
This requires two files at the same level as Makefile.PL -
apxs_win32 and apxs_win32_PL, which I've put up under
http://theoryx5.uwinnipeg.ca/. apxs_win32 isn't the cleanest
script ever been written :); part of the reason is that
I tried to make minimal changes, in case it was desired to
merge the changes at some point into the unix version.
--
best regards,
randy
Re: Apache::Test oustanding issues
On Tue, 29 Jul 2003, Stas Bekman wrote: Randy Kobes wrote: On Tue, 29 Jul 2003, Stas Bekman wrote: In the last few weeks the following two issues were raised: 1) store a default location of httpd/apxs in Apache::Test so one should provide it only once. I'm +1 on this feature. Is anybody interested to implement it? That sounds like a good idea ... Are you thinking of something like Apache::MyConfig.pm of mod_perl 1, or libnet.cfg of libnet - a file which gets created the first time the user installs the package, and then gets used on subsequent locations, with perhaps an initial dialogue asking the user if they want to keep the stored settings? Yes. That's the idea Matt brought up earlier on this list. I'd be interested in taking a look at this ... But just so I understand the intent, - this configuration file would get written at the 'perl Makefile.PL' stage? - if the user supplies -httpd and/or -apxs values to 'perl Makefile.PL', or suitable environment variables are set, a dialogue should be invoked, confirming that the user wants to store these values? - if no such values nor environment variables are supplied, guesses are made, and again the user is asked to confirm? - upon later uses of Apache::Test, these stored values would be used, unless explicit -httpd or -apxs arguments to t/TEST are given, or the appropriate environment variables are set? - is it only httpd and apxs that get stored, or would it be useful to have others (eg, the Apache user, group, or port)? -- best regards, randy
Re: apxs on Win32
On Wed, 30 Jul 2003, Stas Bekman wrote:
+1 on the patch
Randy, whatever you think is the best for win32, please go
ahead with it. Untill we get someone else on win32 involved,
you are pretty much free to decide how to handle things and
what's the best for the user, as long as the changes don't
break the code on other platforms. It's really hard to judge
what's good or less good without seeing the problem. Perhaps
somebody else can do that. I remember Philippe was trying to
set win32 env, but he is now in transition from one continent
to another...
On the other hand, I really dislike the fact that the code gets
too many conditionals, making it much harder to comprehend. We
should consider to use subclasses for win32 (or any other
platform that requires too many special cases). What do you
think? There is no hurry for now, but we should keep it at the
backs of our heads (unless of course you think it's a cool idea
and want to go with it right now ;). The good thing is once
subclassed, there is very little danger that the code on other
platforms will go broken.
You're right that there's getting to be too many conditionals
in places, and subclassing would be a better way to go ...
I'll take a look at that, but I'm going on a bit of a break
in a couple of days - what about for now, doing something like
ModPerl::Build does: have, for some sub
sub whatever {
my $self = shift;
my $what = \{whatever_$^O};
$what = \whatever_default unless defined $what;
$what-($self);
}
sub whatever_default {
}
and then, to add something special for MSWin32, simply define a
sub whatever_MSWin32 {
...
}
which gets used in place of the default. I could redo that
patch in this form easily, if that would be better for now.
--
best regards,
randy
Re: apxs on Win32
On Thu, 31 Jul 2003, Stas Bekman wrote: Randy Kobes wrote: [ .. ] As Bill mentioned in another message, it looks like it would be possible to integrate it within httpd-2.0. So rather than including it within the Apache-Test sources, what I could do is add a post-install script to the Win32 ppm package we have here for Apache-Test that would install the apxs script, if desired - that might be handy for people who'd like to play with it now. Though it won't be available for people with older httpd-2.0. I guess in that case Apache::Test could install it. That's what I was thinking - sorry, I should have been clearer. ppm has a feature that, when one installs a ppm package, a script from some server can optionally be fetched and run (by Perl, or anything, actually). So what I could do for the Apache-Test ppm package we have is use such a script to get the needed files for the apxs script and run and install them (if the user wants) - that way, a person running an older httpd-2.0 could just ppm install Apache-Test from here, and apxs would also get installed (of course, associating this script with Apache-Test is just convenience - a user can fetch and run the script him/herself manually). So this wouldn't require any changes to the Apache-Test sources. -- best regards, randy
Re: Apache::Test oustanding issues
On Mon, 28 Jul 2003, David Wheeler wrote: On Monday, July 28, 2003, at 04:52 PM, Stas Bekman wrote: We do that already. The problem is in the parent path. Try: cd /root ; mkdir t ; chmod 0777 t ; sudo -u 'nobody' perl -le 'print -r t -w _ -x _ ? OK : NOK' Oh, right. That's one thing about Unix that I never got the hang of. But don't you get the username and group from httpd.conf? Couldn't use use that information to do chown and chgrp? David Depending on where the source directory is, you may have to open up a parent directory normally restricted to root to a non-root user, which wouldn't be a good idea, even temporarily. What about just skipping the tests if root is running the tests, and printing out an explanatory message why the tests are skipped? -- best regards, randy
Re: Apache::Test oustanding issues
On Mon, 28 Jul 2003, David Wheeler wrote: On Monday, July 28, 2003, at 06:33 PM, Randy Kobes wrote: What about just skipping the tests if root is running the tests, and printing out an explanatory message why the tests are skipped? I don't think you can necessarily do this, because not all test need to have access to t/. My test suite for MasonX::ApacheHandler::WithCallbacks, for example, doesn't need to have the Apache user access those files. They're loaded up by the user that starts apache (root), and then the process forks off to nobody-owned children that never access the files. So my tests work fine even under root. That's a good point ... As you say below, it'd be better for the test writer to decide on an individual basis which tests should be skipped if run as root. And since many, _many_ users simply install modules via CPAN.pm as root, you'd be eliminating a huge group of people who can run tests. That's true, although that practice is discouraged ... I think this issue has come up in the context of other CPAN modules, where some do skip tests if run as root, for similar reasons - some tests aren't designed for being run as root, and in principle may give false positive (or negative) results if run as such. I think a better idea is to introduce a test function like have_lwp, maybe called has_access_to_t, that can be used by the module developer to skip the relevant tests, if necessary. -- best regards, randy
Re: Apache::Test oustanding issues
On Tue, 29 Jul 2003, Stas Bekman wrote: In the last few weeks the following two issues were raised: 1) store a default location of httpd/apxs in Apache::Test so one should provide it only once. I'm +1 on this feature. Is anybody interested to implement it? That sounds like a good idea ... Are you thinking of something like Apache::MyConfig.pm of mod_perl 1, or libnet.cfg of libnet - a file which gets created the first time the user installs the package, and then gets used on subsequent locations, with perhaps an initial dialogue asking the user if they want to keep the stored settings? -- best regards, randy
apxs on Win32
I've been looking at getting apxs for Win32 working on Apache 2.
There's a number of changes needed due to the current reliance on
libtool, so initially I've tried just a pure Win32 version - if
anyone wants to try it, I've put up two files - Configure.apxs
and apxs.in - at http://theoryx5.uwinnipeg.ca/. Running
C:\Some\Path perl Configure.apxs
(in the same directory as apxs.in) will guess at your Apache2
directory (a --with-apache2=... option can be specified to tell
it explicitly), and then an apxs.bat will be created under
C:\Path\to\Apache2\bin\, along with the associated
C:\Path\to\Apache2\build\config_vars.mk.
I've tried using this for the c-modules tests of perl-framework,
and it seems to work OK, with the following diff applied to
a couple of files under perl-framework/Apache-Test/lib/Apache:
===
Index: TestConfig.pm
===
RCS file:
/home/cvspublic/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm,v
retrieving revision 1.165
diff -u -r1.165 TestConfig.pm
--- TestConfig.pm 7 Jul 2003 18:42:29 - 1.165
+++ TestConfig.pm 29 Jul 2003 05:51:22 -
@@ -283,7 +283,7 @@
$self-{APXS} = $self-default_apxs;
return unless $self-{APXS};
-
+$self-{APXS} =~ s !/!\\!g if WIN32;
my $vars = $self-{vars};
$vars-{bindir} ||= $self-apxs('BINDIR', 1);
Index: TestConfigC.pm
===
RCS file:
/home/cvspublic/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfigC.pm,v
retrieving revision 1.20
diff -u -r1.20 TestConfigC.pm
--- TestConfigC.pm 31 Mar 2003 06:58:40 - 1.20
+++ TestConfigC.pm 29 Jul 2003 05:51:22 -
@@ -76,7 +76,8 @@
EOF
}
-my %lib_dir = (1 = , 2 = .libs/);
+my %lib_dir = Apache::TestConfig::WIN32 ? (1 = , 2 = ) :
+(1 = , 2 = .libs/);
sub cmodules_build_so {
my($self, $name) = @_;
@@ -135,6 +136,9 @@
my $lib = $self-cmodules_build_so($name);
+my $extras;
+$extras = ' -llibhttpd -p ' if Apache::TestConfig::WIN32;
+
my $fh = Symbol::gensym();
open $fh, $makefile or die open $makefile: $!;
@@ -143,7 +147,7 @@
all: $lib
$lib: $name.c
- \$(APXS) $dversion -I$self-{cmodules_dir} -c $name.c
+ \$(APXS) $dversion -I$self-{cmodules_dir} $extras -c $name.c
clean:
-rm -rf $name.o $name.lo $name.slo $name.la .libs
===
(there's a failure in building one of the tests due to a
missing random-ish function). The tests were configured as
C:\perl-framework Perl Makefile.PL -apxs C:\Apache2\bin\apxs
-httpd C:\Apache2\bin\Apache.exe
The reason for specifying both -apxs and -httpd is related to the
current Apache-Test using the fact that the apxs variable TARGET
specifies the name of the httpd binary (httpd). On Win32 the
binary is Apache.exe, but changing the value of TARGET on Win32
would break assumptions elsewhere that the Apache configuration
file (httpd.conf on Win32 as well) is TARGET.conf. How to handle
this better should be looked at.
Merging this Win32 apxs.in and the one in the httpd sources would
possible, if that was desired.
--
best regards,
randy kobes
Re: apxs on Win32
On Tue, 29 Jul 2003, Stas Bekman wrote:
Randy Kobes wrote:
I've been looking at getting apxs for Win32 working on Apache 2.
There's a number of changes needed due to the current reliance on
libtool, so initially I've tried just a pure Win32 version - if
anyone wants to try it, I've put up two files - Configure.apxs
and apxs.in - at http://theoryx5.uwinnipeg.ca/. Running
C:\Some\Path perl Configure.apxs
(in the same directory as apxs.in) will guess at your Apache2
directory (a --with-apache2=... option can be specified to tell
it explicitly), and then an apxs.bat will be created under
C:\Path\to\Apache2\bin\, along with the associated
C:\Path\to\Apache2\build\config_vars.mk.
where would it go? Apache::Test? mod_perl?
If there's consensus, I think the better place would be
Apache-Test, as it can be used outside of mod_perl. If so,
I'll clean things up a bit, and put up a new version; I
could also generate something for Apache-Test's Makefile.PL
to have it configure and install this on Win32, if wanted.
I've tried using this for the c-modules tests of perl-framework,
and it seems to work OK, with the following diff applied to
a couple of files under perl-framework/Apache-Test/lib/Apache:
===
Index: TestConfig.pm
===
RCS file:
/home/cvspublic/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm,v
retrieving revision 1.165
diff -u -r1.165 TestConfig.pm
--- TestConfig.pm 7 Jul 2003 18:42:29 - 1.165
+++ TestConfig.pm 29 Jul 2003 05:51:22 -
@@ -283,7 +283,7 @@
$self-{APXS} = $self-default_apxs;
return unless $self-{APXS};
-
+$self-{APXS} =~ s !/!\\!g if WIN32;
can this please be:
$self-{APXS} =~ s|/|\\|g if WIN32;
os some other separator than !, probably something like s{/}{//}g
Sure, no problem.
my $vars = $self-{vars};
$vars-{bindir} ||= $self-apxs('BINDIR', 1);
Index: TestConfigC.pm
===
RCS file:
/home/cvspublic/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfigC.pm,v
retrieving revision 1.20
diff -u -r1.20 TestConfigC.pm
--- TestConfigC.pm 31 Mar 2003 06:58:40 - 1.20
+++ TestConfigC.pm 29 Jul 2003 05:51:22 -
@@ -76,7 +76,8 @@
EOF
}
-my %lib_dir = (1 = , 2 = .libs/);
+my %lib_dir = Apache::TestConfig::WIN32 ? (1 = , 2 = ) :
+(1 = , 2 = .libs/);
sub cmodules_build_so {
my($self, $name) = @_;
@@ -135,6 +136,9 @@
my $lib = $self-cmodules_build_so($name);
+my $extras;
it must be:
my $extras = '';
+$extras = ' -llibhttpd -p ' if Apache::TestConfig::WIN32;
or:
my $extras = Apache::TestConfig::WIN32 ? ' -llibhttpd -p ' : '';
probably worth adding on top:
use constant WIN32 = Apache::TestConfig::WIN32;
so there will be less to type, shorter lines...
Good idea - I'll fix that too.
my $fh = Symbol::gensym();
open $fh, $makefile or die open $makefile: $!;
@@ -143,7 +147,7 @@
all: $lib
$lib: $name.c
- \$(APXS) $dversion -I$self-{cmodules_dir} -c $name.c
+ \$(APXS) $dversion -I$self-{cmodules_dir} $extras -c $name.c
please always inline and attach the diff when it includes tabs, since they get
lost...
Sorry about that - I'll generate a new diff tonight.
clean:
-rm -rf $name.o $name.lo $name.slo $name.la .libs
===
(there's a failure in building one of the tests due to a
missing random-ish function). The tests were configured as
C:\perl-framework Perl Makefile.PL -apxs C:\Apache2\bin\apxs
-httpd C:\Apache2\bin\Apache.exe
The reason for specifying both -apxs and -httpd is related to the
current Apache-Test using the fact that the apxs variable TARGET
specifies the name of the httpd binary (httpd). On Win32 the
binary is Apache.exe, but changing the value of TARGET on Win32
would break assumptions elsewhere that the Apache configuration
file (httpd.conf on Win32 as well) is TARGET.conf. How to handle
this better should be looked at.
it'd be cool to need to rely only on any of the two.
I'll take a look at this tonight as well - it'd probably
be easier to change, for Win32, the assumption of the
name of the httpd binary when apxs is present.
--
best regards,
randy
Re: Test failure with Apache::Test 1.03, Apache/2.0.40 and perl-5.8.1-to-be
On Tue, 15 Jul 2003, Stas Bekman wrote: Randy Kobes wrote: [ .. ] If the above is on the right track, one possibility is to do the following (in cases where possible LoadModule directives are needed by Apache-Test): - die if an httpd.conf isn't found in a directory conf/ in an expected relative location to httpd (or perhaps add an option allowing a user to specify where httpd.conf is, if it's in a different relative to httpd). This sounds like a good idea to me. Apache::Test already provides an option to specify a custom path to the httpd.conf to inherit from. t/TEST -help | grep inherit -httpd_conf inherit config from this file (default is apxs derived) I didn't see that - that's great ... Does specifying explicitly the working httpd.conf help with your problems, Slaven? - test the configuration, and if an Invalid Command ... error is generated, suggest to the user to either supply the right httpd.conf, or check the validity of the existing one. test the config of httpd.conf to be inherited or the autogenerated one? I was thinking of the inherited one, in case that a wrong one has been picked up. But with the ability there already to specify the httpd.conf to inherit from, perhaps this is overkill. -- best regards, randy
Re: Test failure with Apache::Test 1.03, Apache/2.0.40 and perl-5.8.1-to-be
On Fri, 11 Jul 2003, Stas Bekman wrote: [EMAIL PROTECTED] wrote: [ .. ] Now I get a different failure (Alias is now invalid): [ .. ] waiting for server to start: .Syntax error on line 76 of /home/slavenr/work2/httpd-test/perl-framework/Apache-Test/t/conf/httpd.conf: Invalid command 'Alias', perhaps mis-spelled or defined by a module not included in the server configuration !!! Do you have mod_alias available? % prefork/bin/httpd -l | grep mod_alias mod_alias.c I suppose we could run this command to check for prerequisites and die if they aren't available? I'm not sure what the best way to go about this is, but maybe the following might help in deciding ... I think the problem arises when Apache-Test either doesn't find the right httpd.conf corresponding to the found httpd (as might happen, for example, when httpd is a symlink to the real one), or it finds and parses a bogus one (this happened to me a couple of times when the installed httpd.conf wasn't edited to include the minimal LoadModule directives, and I forgot to check). So it's not necessarily a problem with using an incorrect httpd (although that may still happen), but rather incorrect or missing information from httpd.conf is being used. If the above is on the right track, one possibility is to do the following (in cases where possible LoadModule directives are needed by Apache-Test): - die if an httpd.conf isn't found in a directory conf/ in an expected relative location to httpd (or perhaps add an option allowing a user to specify where httpd.conf is, if it's in a different relative to httpd). - test the configuration, and if an Invalid Command ... error is generated, suggest to the user to either supply the right httpd.conf, or check the validity of the existing one. -- best regards, randy
Re: Test failure with Apache::Test 1.03, Apache/2.0.40 and perl-5.8.1-to-be
On Sun, 6 Jul 2003, Slaven Rezic wrote: make test fails with following output: /usr/perl5.8.1/bin/perl -Iblib/arch -Iblib/lib \ t/TEST -clean APACHE= APXS= APACHE_PORT= APACHE_USER= APACHE_GROUP= \ /usr/perl5.8.1/bin/perl -Iblib/arch -Iblib/lib \ t/TEST -verbose=0 *** root mode: changing the fs ownership to 'nobody' (99:99) /usr/sbin/httpd -d /home/slavenr/.cpan/build/Apache-Test-1.03/t -f /home/slavenr/.cpan/build/Apache-Test-1.03/t/conf/httpd.conf -DAPACHE2 using Apache/2.0.40 (prefork MPM) waiting for server to start: .Syntax error on line 22 of /home/slavenr/.cpan/build/Apache-Test-1.03/t/conf/httpd.conf: Invalid command 'TransferLog', perhaps mis-spelled or defined by a module not included in the server configuration !!! server has died with status 255 (t/logs/error_log wasn't created, start the server in the debug mode) make: *** [run_tests] Terminated I think this is due to it parsing the system httpd.conf (obtained from the location of httpd) and adding to the httpd.conf of Apache-Test any enabled LoadModule directives it finds. I guess this could fail, or get confused, if the httpd.conf of httpd being used isn't a functional one - one possibility is that the httpd specified is a symlink, or is from an Apache source distribution that has not yet been edited. -- best regards, randy kobes
Re: resolving Apache::Test vs. Apache::test collision
On Tue, 17 Jun 2003, Stas Bekman wrote:
[ .. ]
David, please test this patch. This version performs the
cleanup only during 'make install'. what I'm not sure about is
whether it handles correctly some weird paths when creating the
packlist. I think it should work, since nothing is passed via
shell, but goes perl-2-perl.
[ .. ]
I had problems applying the original patch to httpd-test;
manually applying it worked except for an error about
a missing string terminator in the nuke_Apache__test target
(Win32 is picky about using quotes within commands).
This diff:
===
Index: Makefile.PL
===
RCS file: /home/cvspublic/httpd-test/perl-framework/Apache-Test/Makefile.PL,v
retrieving revision 1.8
diff -u -r1.8 Makefile.PL
--- Makefile.PL 29 Apr 2003 06:37:47 - 1.8
+++ Makefile.PL 18 Jun 2003 02:38:58 -
@@ -1,16 +1,21 @@
use 5.005;
+use strict;
+
use ExtUtils::MakeMaker;
use Symbol;
use lib qw(lib);
my $VERSION;
+use File::Spec::Functions qw(catfile catdir);
use Apache::Test5005compat;
use Apache::TestMM qw(test); #enable 'make test'
+my $cleanup_packlist = .mypacklist;
+
Apache::TestMM::filter_args();
my @scripts = qw(t/TEST);
@@ -21,6 +26,8 @@
set_version();
+nuke_Apache__test();
+
WriteMakefile(
NAME = 'Apache::Test',
VERSION = $VERSION,
@@ -59,3 +66,74 @@
return $string;
}
+
+# on Case-Insensitive systems Apache/Test.pm can't coexist with
+# Apache/test.pm, since Apache::test is now deprecated (was renamed to
+# Apache/testold.pm in mod_perl 1.28, we need to find and remove any
+# occurrences of this file. CPAN authors should
+# s/Apache::test/Apache::testold/ and can either require mod_perl 1.28
+# which already carries it or simply bundle it. The best option is to
+# port the test suite to use Apache::Test which works with both
+# mod_perl generations.
+#
+# we could have done this cleanup only for case-insensitive systems,
+# but I feel that doing it for all systems, will speedup the
+# transitions from Apache::test to either Apache::Test or
+# Apache::testold.
+#
+sub nuke_Apache__test {
+
+my @convicts = ();
+foreach (@INC) {
+my $dir = catdir $_, Apache;
+next unless -d $dir;
+opendir DIR, $dir or die Cannot opendir $dir: $!\n;
+my @matches = grep /^test.pm$/, readdir DIR;
+closedir DIR;
+push @convicts, map { catfile $dir, $_ } @matches if @matches;
+}
+
+if (@convicts) {
+print EOI;
+!!! Makefile.PL has found old copies of Apache/test.pm which will
+be removed during 'make install' to prevent collisions with Apache::Test:
+
[EMAIL PROTECTED] \n, @convicts]}
+
+CPAN authors are advised to either use Apache::testold or port their
+test suite to Apache::Test which works with both mod_perl generations.
+EOI
+}
+
+open PACKLIST, $cleanup_packlist
+or die Can't open $cleanup_packlist: $!;
+print PACKLIST join , map $_\n, @convicts;
+close PACKLIST;
+}
+
+sub MY::install {
+my $self = shift;
+
+my $string = $self-MM::install(@_);
+add_dep(\$string, pure_install = 'nuke_Apache__test');
+
+$string;
+}
+
+sub MY::top_targets {
+my $self = shift;
+my $string = $self-MY::top_targets;
+
+$string .= EOF;
+
+nuke_Apache__test:
+\t\$(PERLRUN) -MExtUtils::Install -e uninstall(qq{$cleanup_packlist}, 1, 0)
+EOF
+
+$string;
+}
+
+sub add_dep {
+my($string, $targ, $add) = @_;
+$$string =~ s/($targ\s+::)/$1 $add/;
+}
=
worked for me on Win32 in uninstalling an existing test.pm in all
possible @INC locations before installing the new Test.pm.
Thanks, Stas.
--
best regards,
randy
Re: resolving Apache::Test vs. Apache::test collision
On Thu, 22 May 2003, Stas Bekman wrote: [ ... ] So is everybody happy with this solution? (rename Apache/test.pm with Apache/testold.pm). So we can give Geoff a green light to publish his article? Sounds good ... It'd be very helpful if somebody could do a bit of processing of CPAN and figure who uses Apache::test and compile a list of their email addresses. Here's a list of packages that have Apache::test in their Makefile.PL PREREQ_PMs, or otherwise require by some means Apache::test - this was extracted from some indices used in our CPAN search engine, so may be incomplete. The email addresses could be [EMAIL PROTECTED] === M/MA/MAUNDER/Apache-AppCluster-0.02.tar.gz M/MS/MSCHOUT/Apache-AuthCookie-3.04.tar.gz K/KW/KWILLIAMS/Apache-Compress-1.003.tar.gz J/JI/JIMW/libapreq-1.1.tar.gz B/BO/BORISZ/Apache-PageKit-1.11.tar.gz K/KW/KWILLIAMS/Apache-SSI-2.17.tar.gz K/KW/KWILLIAMS/Apache-Filter-1.022.tar.gz R/RK/RKITOVER/Apache-GDGraph-0.96.tar.gz N/NB/NBYRD/Apache-PAR-0.12.tar.gz S/ST/STAS/Apache-Peek-1.01.tar.gz E/EN/ENRYS/Apache-SessionManager-0.04.tar.gz D/DW/DWHEELER/MasonX-ApacheHandler-WithCallbacks-0.95.tar.gz D/DR/DROLSKY/MasonX-Request-WithApacheSession-0.21.tar.gz = -- best regards, randy
Re: resolving Apache::Test vs. Apache::test collision
On Thu, 22 May 2003, Randy Kobes wrote: On Thu, 22 May 2003, Stas Bekman wrote: [ ... ] It'd be very helpful if somebody could do a bit of processing of CPAN and figure who uses Apache::test and compile a list of their email addresses. Here's a list of packages that have Apache::test in their Makefile.PL PREREQ_PMs, or otherwise require by some means Apache::test - this was extracted from some indices used in our CPAN search engine, so may be incomplete. [ ... ] Just to add to that - this list was those packages that explicitly mention Apache::test in their Makefile.PLs as being needed to build. There may be other packages that use Apache::test but specify it indirectly via something like, eg, mod_perl = 1 or Apache::src in the PREREQ_PM, since Apache::test would be included in the distribution containing these modules. To get an accurate list of those that explicitly use Apache::test one would have to go through and build all packages that use mod_perl (I could put together a list of those), for which there's about 124. Perhaps just mailing all these authors would be simplest, and let them decide if the change would affect them. -- best regards, randy
Re: resolving Apache::Test vs. Apache::test collision
On Fri, 16 May 2003, Geoffrey Young wrote: Stas Bekman wrote: Folks please send your feedback on this last proposal, so we can close this issue asap. In case you have missed it: http://marc.theaimsgroup.com/?l=apache-test-devm=105288551432493w=2 the solution seems reasonable to me, but then again I never had a problem :) from what I remember, this wasn't really an issue on win32 either according to randy (due to the 5.6.1 and 5.8.0 issues or somesuch). so, I guess we just need david and some other OSX people to weigh in before moving forward. maybe committing the solution will help - I feel like we've kinda beat this to death. we can always back it out later if it doesn't work as intended, and having CVS up to date makes it easier for people to test everything. I agree - the solution looks good. So if it's OK with the OSX people ... -- best regards, randy
Re: resolving Apache::Test vs. Apache::test collision
On Tue, 6 May 2003, David Wheeler wrote: On Tuesday, May 6, 2003, at 08:49 AM, Randy Kobes wrote: An upshot of this is that, when installing Apache-Test, a system file Apache/Test.pm or Apache/test.pm should probably be unlinked before copying to the blib/ directory. Yes, and hope that they don't reinstall mod_perl 1 with its Apache/test again. I'm beginning to think that, for all the up-front hassle of it, just renaming it to Apache::Tester or Test::Apache will avoid more headaches in the long run. That's a good point, although as Stas pointed out, it may cause some confusion with those already using Apache::Test. If one views (philosophically) Apache::Test as a major upgrade to Apache::test (with a different API), might it be reasonable to consider replacing those packages that use Apache::test with Apache::Test? For example, in the next mod_perl 1 release, require Apache-Test for the tests, and do away with Apache::test? This would require rewriting the tests, which might be worth it anyway, as a major illustration that Apache-Test works equally well with mod_perl 1 (I'd volunteer to look at that, as I'm on one of the offending systems). I guess one advantage to this, recalling Stas' suggestion of putting the functionality of Apache::test into Apache::Test, is that two quite distinct test frameworks don't have to, officially, be supported. And it also, eventually, addresses the problem of installing mod_perl 1 after an Apache-Test installation and overwriting Apache/Test.pm with Apache/test.pm. The downside, of course, is that mod_perl 1 is very stable, and so major changes like this aren't desireable. Another disadvantage is that there's 3rd party mod_perl 1 modules that use Apache::test (for example, Apache-Filter), and these would be affected. Perhaps a compromise to the above is to just do this on Win32/Mac OSX (or even not changing the test framework at all in mod_perl 1, and just not install Apache/test.pm), and then just print out a warning that this is being done, and why. This wouldn't affect as many users, and in the Win32 world, and perhaps also on the Mac, I think users are used to major upgrades that aren't necessarily backwards compatible. -- best regards, randy
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestRun.pm
On Fri, 31 Jan 2003, Stas Bekman wrote:
[EMAIL PROTECTED] wrote:
stas2003/01/30 16:53:45
Modified:perl-framework/Apache-Test/lib/Apache TestRun.pm
Log:
# handle the cases when the test suite is run under 'root':
#
# 1. When user 'bar' is chosen to run Apache with, files and dirs
#created by 'root' might be not writable/readable by 'bar'
#
# 2. when the source is extracted as user 'foo', and the chosen user
#to run Apache under is 'bar', in which case normally 'bar' won't
#have the right permissions to write into the fs created by 'foo'.
#
# We solve that by 'chown -R bar.bar t/' in a portable way.
#
# at the end of the run we restore the perms to the original ones
Randy, can you please check that this handles the win32 case as well? I've no
clue whether the concept of 'root' applies there.
Hi Stas,
On Win32, I get an error about getpwuid($) being
unimplemented. This diff
==
Index: Apache-Test/lib/Apache/TestRun.pm
===
RCS file:
/home/cvspublic/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.100
diff -u -r1.100 TestRun.pm
--- Apache-Test/lib/Apache/TestRun.pm 31 Jan 2003 00:53:45 - 1.100
+++ Apache-Test/lib/Apache/TestRun.pm 31 Jan 2003 04:38:35 -
@@ -667,7 +667,7 @@
my $self = shift;
%original_t_perms = (); # reset global
-my $user = getpwuid($) || '';
+my $user = Apache::TestConfig::WIN32 ? '' : (getpwuid($) || '');
if ($user eq 'root') {
my $vars = $self-{test_config}-{vars};
my $user = $vars-{user};
===
allows things to run.
--
best regards,
randy
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestRun.pm
On Fri, 31 Jan 2003, Stas Bekman wrote: Is the whole test-under-'root' issue moot under win32, and can be safely skipped without messing the code? Hi Stas, There is a concept of permissions under Win32 (some flavours) which in principle can enter this (for example, an Administrator can block users from modifying certain system settings). However, I've not had, or heard of, such problems in this context of testing Apache. Probably if they did arise a much different logic would have to be used. -- best regards, randy
Re: Asst'd Win32 failures [that should simply be skipped]
On Sat, 22 Jun 2002, William A. Rowe, Jr. wrote:
This one is just plain silly, looks like a semantics error...
modules\include.t 516 11.76% 46-51
ok 36
ok 37 # Skipping XBitHack tests on this platform
ok 38 # Skipping XBitHack tests on this platform
ok 39 # Skipping XBitHack tests on this platform
ok 40 # Skipping XBitHack tests on this platform
ok 41 # Skipping XBitHack tests on this platform
ok 42 # Skipping XBitHack tests on this platform
ok 43 # Skipping XBitHack tests on this platform
ok 44 # Skipping XBitHack tests on this platform
ok 45 # Skipping XBitHack tests on this platform
FAILED tests 46-51
Failed 6/51 tests, 88.24% okay (-9 skipped tests: 36 okay, 70.59%)
Since when is a skip == failure :-?
The following
===
Index: t/modules/include.t
===
RCS file: /home/cvspublic/httpd-test/perl-framework/t/modules/include.t,v
retrieving revision 1.21
diff -u -r1.21 include.t
--- t/modules/include.t 20 Jun 2002 04:05:04 - 1.21
+++ t/modules/include.t 22 Jun 2002 21:31:00 -
@@ -141,9 +141,9 @@
for (1..9) {
skip Skipping XBitHack tests on this platform, 1;
}
-exit;
+#exit;
}
-
+else {
### XBITHACK TESTS
# test xbithack off
$doc = xbithack/off/test.html;
@@ -189,7 +189,7 @@
XBitHack full [0554]
);
-
+}
### MOD_BUCKETEER+MOD_INCLUDE TESTS
# we can use mod_bucketeer to create edge conditions for mod_include, since
# it allows us to create bucket and brigade boundaries wherever we want
===
is one way of fixing this.
best regards,
randy kobes
Re: Outch - what a tangled web.
- Original Message - From: Doug MacEachern [EMAIL PROTECTED] To: William A. Rowe, Jr. [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; dev@apr.apache.org Sent: Saturday, January 05, 2002 6:38 PM Subject: Re: Outch - what a tangled web. i wouldn't object to special casing to make win32 happy. though i find it odd that things are working ok as-is on my win32 box and on others. is there any info i can give you about my win32 setup that would help? fwiw your script outputs the following on my box: localhost is at 127.0.0.1 127.0.0.1 is named bramble bramble is at 10.0.1.2 10.0.1.2 is named bramble For one more data point, on my Win98 machine, which is on a dial-up network without a permanent ip address, the script gives localhost is at 127.0.0.1 127.0.0.1 is named localhost localhost is at 127.0.0.1 127.0.0.1 is named localhost and the modules/access.t tests all pass. best regards, randy kobes
Re: Begging your pardons,
- Original Message - From: William A. Rowe, Jr. [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, December 28, 2001 10:55 PM Subject: Begging your pardons, but is anyone familiar with the following failure cases on win32? modules\access..FAILED tests 4, 20-21, 24, 26, 28, 30, 38, 55, 72, 89, 106-1 07, 123-124, 141, 154, 168, 170, 175, 192, 209, 226, 277, 290, 304, 306, 311, 32 8, 345, 362 Failed 31/408 tests, 92.40% okay modules\dav.FAILED test 4 Failed 1/14 tests, 92.86% okay modules\negotiation.FAILED tests 1-3, 24-26, 70-72 Failed 9/98 tests, 90.82% okay [ ... ] I didn't have dav nor ssl set up, but with the latest cvs apache-2 all the access and negotiation tests passed on my Win98 machine. I've seen in some cases that a failure in an early test may cause latter tests to fail that otherwise would have passed (eg, by running tests individually). best regards, randy kobes
