httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: more on the perl-framework on windows
Date Mon, 29 Mar 2004 19:39:43 GMT
Stas Bekman wrote:
> Geoffrey Young wrote:
> 
>>
>> Rodent of Unusual Size wrote:
>>
>>> Randy Kobes wrote:
>>>
>>>
>>>> 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.
>>>
>>>
>>>
>>> the problem is that on the systems in question there IS NO
>>> nmake.  i want to completely short-circuit any and all parts
>>> of -clean, -stop, -config, and testing that a) cleans the
>>> modules out and b) tries to build them.  in other words,
>>> i want to know what i need to do to just have the bloody
>>> thing USE what i put there, without it trying to be smart.
>>
>>
>>
>> I'm happy to work on this, and I can sense your frustration. if I 
>> understand
>> you correctly, what you want to do is this:
>>
>> $ perl Makefile.PL -apxs /apache/2.0.48/worker/perl-5.8.3/bin/apxs
>> $ t/TEST -conf
>>
>> and then copy all the resulting configurations, .so files, etc to a 
>> box that
>> doesn't have make and still run the perl-framework.  yes?
>>
>> anyway, so I ran the above two lines then tarred up the results and 
>> untarred
>> to a different directory.  I even removed the apxs binary.  with the
>> attached patch
>>
>> $ t/TEST
>>
>> seems to work fine.  the difference is that instead of running 't/TEST
>> -clean' behind the scenes when a new cwd is detected I run 't/TEST -conf'
>> which seems to be a bit more intelligent but still allows the tests to 
>> run.
>>
>> let me know if this helps you at all.
>>
>> --Geoff
>>
>>
>> ------------------------------------------------------------------------
>>
>> Index: Apache-Test/lib/Apache/TestRun.pm
>> ===================================================================
>> RCS file: 
>> /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
>> retrieving revision 1.162
>> diff -u -r1.162 TestRun.pm
>> --- Apache-Test/lib/Apache/TestRun.pm    25 Mar 2004 01:31:28 -0000    
>> 1.162
>> +++ Apache-Test/lib/Apache/TestRun.pm    29 Mar 2004 17:40:11 -0000
>> @@ -771,11 +771,11 @@
>>          unlink $config_file . $^I;
>>      }
>>  
>> -    my $cleanup_cmd = "$^X $0 -clean";
>> -    warning "cleaning up the old config";
>> +    my $config_cmd = "$^X $0 -conf -httpd " . $cfg->{vars}->{httpd};
>> +    warning "reconfiguring via $config_cmd";
>>      # XXX: do we care to check success?
>> -    system $cleanup_cmd;
>> -
>> +    system $config_cmd;
>> +        # XXX: I tried hard to accomplish that w/o starting a new 
>> process,
>>      # but too many things get on the way, so for now just keep it as an
>>      # external process, as it's absolutely transparent to the normal
> 
> 
> I don't think this is right, Geoff. You absolutely need to run -clean, 
> w/o which stale information in t/conf/ will persist and break the test 
> suite. What we are after here is cleaning t/conf/ (and any other config 
> dirs, like t/conf/ssl) only. Therefore perhaps we need to introduce a 
> smaller scoped clean target like configclean, which will only touch 
> config files but won't nuke the c-modules. 

or may be the config logic needs more polishing. I did try to avoid -clean, 
but it was failing in several cases :( Relative paths will be perfect for this 
purpose, but again for other purposes they are too error prone.

> Once in place, the correct 
> patch would be:
> 
>  > -    my $cleanup_cmd = "$^X $0 -clean";
>  > +    my $cleanup_cmd = "$^X $0 -configclean";
> 
> but I'm not sure it'll work, because config includes information about 
> compiled modules and when nuked will forget it.

Actually, -configclean is bad choice of name since it will force us to type 
-config for the other target.

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

Mime
View raw message