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
getting config file in TestConfigParse.pm
I was wondering about this change:
http://svn.apache.org/viewcvs.cgi/perl/Apache-Test/trunk/lib/Apache/TestConfigParse.pm?rev=279322&r1=226979&r2=279322
in TestConfigParse.pm, which reads in part:
# SERVER_CONFIG_FILE might be an absolute path
-$file = $default_conf if !-e $file and -e $default_conf;
+if (! -e $file && -e $default_conf) {
+$file = $default_conf;
+}
+else {
+ # try a little harder
+ if (my $root = $self->{httpd_defines}->{HTTPD_ROOT}) {
+ debug "using HTTPD_ROOT to resolve $default_conf";
+ $file = catfile $root, $default_conf;
+ }
+}
}
}
If $file does exist, then the
if (! -e $file && -e $default_conf) {
}
is ignored, but the
else {
}
will be followed; in my case, on Win32, it overwrote
the correct, exisiting $file with
$file = catfile $root, $default_conf;
which didn't exist. The following patch:
=
Index: Apache-Test/lib/Apache/TestConfigParse.pm
===
--- Apache-Test/lib/Apache/TestConfigParse.pm (revision 293219)
+++ Apache-Test/lib/Apache/TestConfigParse.pm (working copy)
@@ -347,15 +347,17 @@
$file = catfile $base, $default_conf;
# SERVER_CONFIG_FILE might be an absolute path
-if (! -e $file && -e $default_conf) {
-$file = $default_conf;
-}
-else {
-# try a little harder
-if (my $root = $self->{httpd_defines}->{HTTPD_ROOT}) {
-debug "using HTTPD_ROOT to resolve $default_conf";
-$file = catfile $root, $default_conf;
+unless (-e $file) {
+if (-e $default_conf) {
+$file = $default_conf;
}
+else {
+# try a little harder
+if (my $root = $self->{httpd_defines}->{HTTPD_ROOT}) {
+debug "using HTTPD_ROOT to resolve $default_conf";
+$file = catfile $root, $default_conf;
+}
+}
}
}
}
==
fixed that for me.
--
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 Wed, 8 Dec 2004, Stas Bekman wrote: > I've requested to restore it (you indeed don't have it). Let me know if > you want me to commit this or wait for when you get the access again > (should hopefully be restored tomorrow). Thanks, Stas. If you have a minute, feel free to commit it; otherwise, I'll do it when it's restored. Thanks. -- 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 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
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
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 Wed, 1 Dec 2004, Stas Bekman wrote: > Randy Kobes wrote: [ ... ] > > 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. > > It wasn't updated yet, so I did the above and now it's updated. > > But for some reason the headers > License + search site are shifted to the right (wrong level?) I noticed that too, but that's how it was originally (if I remember correctly). I could change that, if desired. -- 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, Stas Bekman wrote: > Randy Kobes wrote: [ ... ] > > 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)? > > It won't work since the version number lives in the > package mod_perl. and most likely you'd want to require a > minimal version at some point. That's true - I forgot about that ... One could tie the version of Apache.pm (for mp1) or Apache2.pm (for mp2) to the corresponding mod_perl.pm version, and make a note of that in the RELEASE notes, but I agree, that's not addressing the underlying issue. -- 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: 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: [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: 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: 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 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: [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: 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: 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 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: > 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 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, 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: 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: 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
in-place edit in TestRun.pm
Hi,
A recent change in Apache-Test/lib/Apache/TestRun.pm
involves an in-place edit, at around line 765:
local @ARGV = $config_file;
while( <> ) {
s/old/new/;
print;
}
Unfortunately, Win32 can't do such in-place edits:
for example,
perl -spi -e 's#old#new#' file.txt
won't work, but
perl -spi.bak -e 's#old#new#' file.txt
will. Would something like
my $orig = $config_file . '.orig';
rename $config_file, $orig or die "...";
open(my $rfh, $orig) or die "...";
open(my $wfh, '>', $file) or die "...";
while(<$rfh>) {
s{old}{new}g;
print $wfh $_;
}
close $rfh;
close $wfh;
unlink $orig;
be OK?
--
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 Wed, 18 Feb 2004, Stas Bekman wrote:
> Randy Kobes wrote:
> Thanks for testing, Randy
>
> >>+for my $key (keys %conf_opts) {
> >>+next unless Apache::TestConfig::conf_opt_is_a_filepath($key);
> >>+$conf_opts{$key} = Win32::GetShortPathName($conf_opts{$key});
[ ... ]
>
> ay, that's so incredibly here>. there is no a core function that will take any
> given path and return a usable path?
>
> do you need to run this transform only if /\s/? What about
> long names (>8.3), don't they have short names too?
Yes, they do have short names. And it is a pain ... I should
have expanded - Win32::GetShortPathName() will return a
usable path if the file/directory physically exists - if a
conversion to 8.3 components is needed, then that is done,
otherwise, the original is returned. However, at this stage
I don't think (?) we can assume the file/directory yet
exists, at least for all the ones that this is being applied
to, so calling Win32::GetShortPathName on them will cause
the given values to be lost if they don't yet exist.
So, actually, I take that back about applying
Win32::GetSHortPathName($f) only if $f =~ /\s/, as that
was a red herring - doing it like
for my $key (keys %conf_opts) {
next unless Apache::TestConfig::conf_opt_is_a_filepath($key);
next unless -e $conf_opts{$key};
$conf_opts{$key} = Win32::GetShortPathName($conf_opts{$key});
should be OK when the entry (physically) exists, whether
that's a short or long name, and if it doesn't exist,
presumably it will either be created or tested for later.
One might have to do a Win32::GetShortPathName() if such an
entry does get created later on, but we could wait and see.
> For god's sake, can someone patch File::Spec to handle
> that win32 ridicule? Just think how much time every
> project wastes to deal with the same issues, again and
> again if they need to work with win32... not talking about
> making the source code cluttered with unneeded noise.
> that's just disgusting.
>
> Shouldn't canonfile() know how to deal with this
> GetShortPathName thingy?
I guess it could, but that would involve somewhat of a
departure from the philosophy of File::Spec. File::Spec can
handle any combination of files/directories, whether or not
they actually exist on the system, whereas things like
Win32::GetShortPathName() only makes sense for
files/directories that physically exist. So incorporating
the short path name stuff in File::Spec would lead to a
branch in what gets returned, depending on whether or not
the entry physically exists.
> /of course none of these "flattering" comments are
> directed at Randy and other brave and helpful folks ;)/
:)
--
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: 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: 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: 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: 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
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 Sat, 10 Jan 2004, Stas Bekman wrote: > Randy Kobes wrote: > > 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? > > But that works only for mp2. How does A-T knows whether a > user wants mp2 and not mp1? I think if they have mp2, they > have had a chance to get apxs2 alredy, no? That's true about a user already getting the chance to get a development apxs with mp2 - I was wondering though about doing the same for Apache2 within the perl-framework (the apxs that is offered with mp2 will work outside of mp2, as it just requires Apache2 - for example, it builds and runs the c-modules tests under httpd-test/perl-framework/). So here we would just have to check for Apache2. -- 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 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
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
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
Re: sticky preferences in Apache-Test
On Tue, 6 Jan 2004, Stas Bekman wrote: > OK, here is a an extended version of Randy's original work > to be able to save and reuse A-T config. I've added first > time interactive configuration feature (similar to > CPAN.pm). It took me a long time to polish it as there are > so many possible cases on how this new feature can be > used, it was pretty tricky. I haven't quite tested -save > too. Also there could be some issues with win32, I'm sure > Randy will post a fix. It's a pretty big patch, let me > know if you want me to commit it and we will take it from > there, making it easier to users to test it. We probably > need to polish it somewhat. Great work, Stas! This is a deceptively tricky problem ... I for one would find it really convenient if you could commit it and work on it from there - I have trouble with longish patches getting them onto my Win32 system. -- 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;
+
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 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.
[ .. ]
> Just a sanity check, the env var overrides (.e.g. USER)
> come in later, right?
I checked that the environment variables Apache::Test
recognizes do override the settings in
Apache::TestConfigData, if they are set, and will be saved
to Apache::TestConfigData if -save is passed to t/TEST.
I think I got the indentation right this time. Also,
I've added in a bit of pod to describe this.
==
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 6 Sep 2003 15:40:09 -
@@ -10,20 +10,67 @@
use Apache::TestRequest ();
use Apache::TestHarness ();
use Apache::TestTrace;
+use Apache::TestUtil qw(win32_long_path);
+
+use Cwd;
+# Are we building things within Apache-Test?
+sub in_apache_test {
+my $cwd = win32_long_path(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 qw(dirname);
use Config;
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 +102,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 +455,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 +559,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});
}
@@ -917,6 +971,41 @@
CORE::exit $_[0];
}
+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;
+die "Cannot open $file: $!" unless (open($fh, ">$file"));
+warn "Writing $file.\n";
+my $config_dump = '';
+if ($self->{test_config}->{vars}->{h
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 %{$
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;
+$s
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";
+pac
Re: need help to add per-user config to Apache::Test
[ trimmed mod_perl mailing list from cc ]
On Fri, 29 Aug 2003, Randy Kobes wrote:
> 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.
A stab at this follows ... It's rough, as I wanted to
make sure this was on the right track; basically, what's
supposed to happen is
- if a Apache::MyTestConfig is found, use the values for
apxs, httpd, user, group, and port stored in there. These
values get overridden if they appear as arguments to 'perl
Makefile.PL'.
- if no Apache::MyTestConfig is present, or a '-save'
option is passed to 'perl t/TEST', Apache::MyTestConfig
is created, and then installed.
- the location of Apache::MyTestConfig is, first of all,
under $HOME/.apache-test/, or if this is not present,
under the system @INC.
I'm not sure I'm putting the values of
Apache::MyTestConfig in the right, or best, place;
I haven't tested it extensively, as my linux box
is a live server.
=
Index: TestConfig.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm,v
retrieving revision 1.171
diff -u -r1.171 TestConfig.pm
--- TestConfig.pm 13 Aug 2003 19:02:51 - 1.171
+++ TestConfig.pm 1 Sep 2003 03:51:13 -
@@ -3,6 +3,22 @@
use strict;
use warnings FATAL => 'all';
+require File::Spec;
+sub has_config {
+my $has_config = 0;
+if ($ENV{HOME}) {
+eval
+{require File::Spec->catfile($ENV{HOME},
+ '.apache-test', 'MyTestConfig.pm');};
+$has_config = 1 unless $@;
+}
+unless ($has_config) {
+eval {require Apache::MyTestConfig;};
+$has_config = 1 unless $@;
+}
+return $has_config;
+}
+
use constant WIN32 => $^O eq 'MSWin32';
use constant CYGWIN => $^O eq 'cygwin';
use constant NETWARE => $^O eq 'NetWare';
@@ -24,8 +40,8 @@
use File::Path ();
use File::Spec::Functions qw(catfile abs2rel splitdir canonpath
catdir file_name_is_absolute);
-use Cwd qw(fastcwd);
+use Cwd qw(fastcwd);
use Apache::TestConfigPerl ();
use Apache::TestConfigParse ();
use Apache::TestTrace;
@@ -34,6 +50,8 @@
use vars qw(%Usage);
+use constant HAS_CONFIG => has_config();
+
%Usage = (
top_dir => 'top-level directory (default is $PWD)',
t_dir => 'the t/ test directory (default is $top_dir/t)',
@@ -72,6 +90,12 @@
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->{$_};
+}
+}
my(@pass, %keep);
my @filter = @$args;
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 1 Sep 2003 03:51:14 -
@@ -11,10 +11,14 @@
use Apache::TestHarness ();
use Apache::TestTrace;
+use constant HAS_CONFIG => Apache::TestConfig::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 +27,7 @@
my %original_t_perms = ();
my @std_run = qw(start-httpd run-tests stop-httpd);
-my @others = qw(verbose confi
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 Wed, 30 Jul 2003, William A. Rowe, Jr. wrote:
> At 10:09 PM 7/29/2003, Randy Kobes wrote:
>
> >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.
>
> I think the right solution here is to provide two seperate
> flags for apxs to determine the name of the "conf file" v.s.
> the name of the "binary".
That does seem the better solution ... It would mean changing
httpd-2.0's apxs.in, where $CFG_TARGET is set to "progname"
(httpd), and this is used, for example, to edit the
$CFG_TARGET.conf file to activate modules.
> Call me crazy but it seems pretty simple :-) Only question, does the
> old option preserve the 'binary name' or the 'conf name'?
Right now, within Apache-Test, apxs -q target is used as the
name of the Apache binary to search for (I haven't seen yet a
a use of it within Apache-Test for the name of the conf file).
And this seems more in tune with the fact that "target" is
derived from "progname" in config_vars.mk.
> I suspect we want to use the original flag as the 'binary
> name'. The new flag to return the '.conf name' should properly
> decorate it with .conf on all platforms. And the original flag
> can be used to retrieve the decorated 'Apache2.exe' program
> name on Win32.
That sounds good ... There already is a "sysconfdir"
(eg., /usr/local/apache2/conf/) - what about "sysconf"
( = httpd.conf ) to represent the conf file? I'll revise
the scripts (apxs_win32, and the configuration script
apxs_win32_PL, under http://theoryx5.uwinnipeg.ca/) to
reflect this.
> I'm really excited about trying your implementation, although I'm a
> bit backlogged after traveling this weekend. Certainly this belongs
> in httpd-2.0/build/ once we dot all the I's and cross the t's.
>
> If you don't object, once I give it the once-over, I'll commit
> it after I can address any minor quibbles to the httpd 2.1 dev
> branch, and we can work from there on improving it.
Sounds good!
> We should definately look to make this usable for our Netware
> users as well, who might not be using a full gcc environment,
> but tools like codewarrior suite, etc. I'm not saying we
> commit to this, but if we can keep some bits pretty abstract,
> it will be easy for another contributor to come along and
> connect the dots. {maybe it's already this way, I promise to
> delve into the code this week :-}
Right now the script has minimal changes, as I wasn't sure
if it was desired to merge the changes into the unix version.
But working with Stas has made me appreciate the value of clean,
extendable code :) - it would be fun to go through this and
make it easier to be more portable.
--
best regards,
randy
Re: apxs on Win32
On Thu, 31 Jul 2003, Stas Bekman wrote: > Randy Kobes wrote: [ .. ] > > 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 [ ... ] > Thanks Randy, I did understand that. I was asking about those who try to > install from source, without using ppm. Ah, I see now ... What could be done, within Apache-Test's Makefile.PL, is offer to get the same remote source and configuration files to install apxs that the ppm post-install script gets. This would be easier to maintain and upgrade, and plus wouldn't require adding additional files to the Apache-Test distribution. -- 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: apxs on Win32
On Wed, 30 Jul 2003, Stas Bekman wrote: > Randy Kobes wrote: [ .. ] > > 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. > > Where apxs_win32_PL is coming from? Is it possible to somehow integrate it > within httpd-2.0? 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. -- 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: 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 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 $file"unless $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: 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:
> > 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
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: 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
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 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: 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 <$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 .= <
Re: resolving Apache::Test vs. Apache::test collision
On Fri, 23 May 2003, Stas Bekman wrote: > > Fantastic, Randy! There are very few as expected. > > Can we simply grep for Apache::test in all files (not only > Makefile.PL) and then 'find . |grep Apache/test.pm' to exclude > those who bundle the package? By a strange coincidence, the system I have extracts those .pm files that have pod content, so this was simple to find - the packages that include an Apache::test are Apache-AppCluster/Server/t/Apache/test.pm Apache-AuthCookie/t/Apache/test.pm Apache-Compress/t/Apache/test.pm Apache-Filter/t/Apache/test.pm Apache-SSI/t/Apache/test.pm AxKit-Needs/mod_perl/mod_perl-1.26/Apache/test.pm HTML-Mason/t/Apache/test.pm mod_perl/Apache/test.pm MasonX-ApacheHandler-WithCallbacks/t/Apache/test.pm This was done on Linux, so Apache/test.pm really is Apache::test, and not Apache::Test :) -- 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 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 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-dev&m=105288551432493&w=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, 13 May 2003, Stas Bekman wrote: [ .. ] > This is what I see now as the simplest solution at all fronts: > > 1) keep the distro name Apache-Test. > > 2) s|Apache/Test.pm|Apache/TestPlan.pm| > > 3) contents of Apache/TestPlan.pm: > > package Apache::Test; > $Apache::Test::VERSION = '1.02'; > package Apache::TestPlan; > # what was previously Apache::Test code follows > > I decided to nevertheless plug these two lines in: > > package Apache::Test; > $Apache::Test::VERSION = '1.02'; > > so that CPAN will still index Apache::Test, and we can still > tell CPAN.pm to install Apache::Test, same for dependencies > list. Also that's where we maintain the distro's version. I'm not familiar enough with how PAUSE indexes modules contained in a distribution ... Does it search all .pm files for package declarations and index what it finds? For example, CPAN.pm itself contains several packages in the same file, but these don't show up in the indices (but that might be because these modules haven't been registered in PAUSE). > Usage-wise, the only change you have to do is this: > > perl -pi -e 's|use Apache::Test([\s;])|use Apache::TestPlan$1|' files > > Is everybody happy with that solution? That sounds good ... So with this Apache::test of mod_perl 1 wouldn't be affected at all? -- best regards, randy
Re: resolving Apache::Test vs. Apache::test collision
On Fri, 9 May 2003, Stas Bekman wrote: [ .. ] > Yes, that shouldn't be a problem. > > So currently we are down to two options: > > 1) Integrate test.pm in Test.pm. I think we should bundle > Apache::Test with future versions of mod_perl to make the > maintenance simple and remove the original Apache::test from > it. > > 2) Rename Apache::Test to Apache::Tester (or else) to resolve > the collision. Rename the distro Apache-Test to > Apache-TestHarness (or else) to avoid confusion. > > Looks like if we can provide a clean implementation of (1) > that's would be the best solution. Randy says that it shouldn't > be a problem with winFU. If David says that it's cool with > MacOSX, let's try to take this route then. I'd tend to agree with (1) ... Would that mean that mod_perl 1 (and any 3rd party mod_perl 1 packages that use it) would have to change a 'use Apache::test' to 'use Apache::Test'? Or would Apache/test.pm become an identical copy of Apache/Test.pm, with both being installed? -- best regards, randy
Re: resolving Apache::Test vs. Apache::test collision
On Thu, 8 May 2003, Stas Bekman wrote: > The problem with providing a replacement for Apache::test is > that some people are going to reinstall older mod_perl versions > and kill the overriden file. That's certainly true in general (for case-preserving but otherwise case-insensitive file systems) - I just thought I'd clarify why this problem never really arose before on ActivePerl Win32. There, mod_perl 1 works with perl-5.6.1 but not with perl-5.8.0 (due to large files support), and mod_perl 2 works with perl-5.8.0, but not (practically speaking) with perl-5.6.1. So it's very rare that Apache::test and Apache::Test would get installed within the same Perl tree, at least while these two were tied to particular mod_perl versions. -- best regards, randy
Re: resolving Apache::Test vs. Apache::test collision
On Thu, 8 May 2003, Stas Bekman wrote: [ .. ] > One question remains: should the package be renamed to > Apache-Tester as well? Since people will see Apache::Test and > will try to install Apache::Test in CPAN.pm, and that won't > work. Probably to make a clean break the whole package should be renamed. And also, probably the current Apache-Test packages on CPAN should be deleted, as Apache::Test would still show up in the CPAN indices, under older Apache-Test packages (eg, there's some obsolete modules in older versions of libwww-perl that can be seen within CPAN.pm). I think though that the Apache::Test module would still remain in the indices after such deletion, and CPAN.pm would direct queries to the module owner. You'll probably have to contact modules@perl.org to get the module itself removed from the indices. -- 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: resolving Apache::Test vs. Apache::test collision
On Mon, 5 May 2003, Geoffrey Young wrote: > Stas Bekman wrote: > > We have a problem with using the Apache::Test name, more > > correctly we have a problem with using the Apache/Test.pm > > filename. On platforms with case-insentive filesystems > > (winFU, Mac OS X) if mod_perl 1.x is installed, there is > > Apache/test.pm (notice the lower case 't'). So when you say > > 'use Apache::Test' it loads Apache::test. Boom, nothing > > works. > > ok, so it's not like that I don't believe that this is an issue, but I > don't believe you - if you have Apache/test.pm and you install 2.0 > then Apache/Test.pm would replace the existing file, no? that's why > Apache2 is around for all the mod_perl based stuff - to keep > Apache::Filter from 2.0 from cloberring Apache::Filter from 1.0 > > if installing Apache::Test doesn't clobber Apache::test on > case-insensitive installations, _that_ seems like a bug to me :) On Win32, at least, installing Apache::Test will clobber Apache::test, but, from what I've experienced, it will copy the Apache/Test.pm from blib/ to the system Apache/test.pm. So one ends up with an Apache::test that is actually Apache::Test. And vice versa - if you install, on a fresh system, Apache::Test, so that you have a system Apache/Test.pm, and then install Apache::test from mod_perl 1, you'll end up with an Apache::Test that is actually Apache::test. This isn't a Perl thing - from a DOS window, suppose one has C:\test.txt C:\tmp\tESt.txt Then doing a C:\> copy C:\temp\tESt.txt C:\ will result in C:\test.txt (actually being C:\tmp\tESt.txt). 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. -- 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: 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: 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]>; 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
