Geoff, why did you make APACHE_TEST_NO_STICKY_PREFERENCES prevent from saving autoconfig?

sub custom_config_save {
    my $self = shift;

    if ($ENV{APACHE_TEST_NO_STICKY_PREFERENCES}) {
        debug "skipping save of custom config data";
        return;
    }

I mean, APACHE_TEST_NO_STICKY_PREFERENCES already prevents the loading of that config, why not let saving you. It breaks the interactive configuration process which we need to add to the RELEASE doc to test. I try to do:

env APACHE_TEST_NO_STICKY_PREFERENCES=1 perl-5.8.4-ithread Makefile.PL
env APACHE_TEST_NO_STICKY_PREFERENCES=1 APACHE_TEST_TRACE_LEVEL=debug make test

and when the interactive config is over, we get:

skipping save of custom config data
rerunning '/home/stas/perl/5.8.4-ithread/bin/perl5.8.4 /tmp/Apache-Test/t/TEST -bugreport -verbose=0' with new config opts
trying to load custom config data
...


and so we get into interactive config again.

Granted, instead of using APACHE_TEST_NO_STICKY_PREFERENCES one could go and delete the custom config files, but one needs to find them first and it's error prone for testing. I'd like to see APACHE_TEST_NO_STICKY_PREFERENCES do its job w/o getting on the way of things that we need to test.

Besides removing that clause in custom_config_save we also need to turn off that env var, after custom config is over, in order to pick up those vars. So overall it looks like:

Index: lib/Apache/TestRun.pm
===================================================================
RCS file: 
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.169
diff -u -r1.169 TestRun.pm
--- lib/Apache/TestRun.pm       13 May 2004 01:09:26 -0000      1.169
+++ lib/Apache/TestRun.pm       20 May 2004 19:58:12 -0000
@@ -1412,11 +1412,6 @@
 sub custom_config_save {
     my $self = shift;

-    if ($ENV{APACHE_TEST_NO_STICKY_PREFERENCES}) {
-        debug "skipping save of custom config data";
-        return;
-    }
-
     my $vars = $self->{test_config}->{vars};
     my $conf_opts = $self->{conf_opts};
     my $config_dump = '';
@@ -1684,6 +1679,8 @@
     # the problem is various cached data which won't be refreshed. so
     # the simplest is just to restart the run from scratch
     chdir $orig_cwd;
+    # we also need to enable sticky preferences, otherwise re-run will fail
+    $ENV{APACHE_TEST_NO_STICKY_PREFERENCES} = 0;
     warning "rerunning '$original_command' with new config opts";
     exec $original_command;
     die "exec $original_command has failed"; # shouldn't be reached

If applied now all we need is to add one more step to RELEASE testing 
procedures:

Index: RELEASE
===================================================================
RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/RELEASE,v
retrieving revision 1.9
diff -u -r1.9 RELEASE
--- RELEASE     19 Apr 2004 02:38:58 -0000      1.9
+++ RELEASE     20 May 2004 20:02:16 -0000
@@ -4,13 +4,25 @@
    etc. Now test this generated package (not cvs) with as many
    configurations as possible on as many platforms as possible.

-  a. nuke any preinstalled Apache-Test libs and run 'make test'
+  a. copy Apache-Test away from within the modperl-2.0 build, since it
+     affects the way things are configured.

-  b. test that you can 'make install' and then run 'make test' again
+  b. nuke any preinstalled Apache-Test libs and run 'make test'

-  c. test whether we still 100% OK on systems with no LWP:
+  c. test that you can 'make install' and then run 'make test' again
+
+  d. test whether we still 100% OK on systems with no LWP:

      % APACHE_TEST_PRETEND_NO_LWP=1 make test
+
+  e. now test without sticky config, which involves an interactive
+     custom config:
+
+     % APACHE_TEST_NO_STICKY_PREFERENCES=1 perl-5.8.4-ithread Makefile.PL
+     % APACHE_TEST_NO_STICKY_PREFERENCES=1 make test
+
+     the env var is needed for both steps, to avoid picking up
+     preconfigured data.

 2. once confident that the package is good, upload a release candidate
    to perl.apache.org/~username and post 24 hour-ish candidate alert


This step would have detected the problem William has reported.

--
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Reply via email to