You are viewing a plain text version of this content. The canonical link for it is here.
Posted to test-dev@httpd.apache.org by Rodent of Unusual Size <Ke...@Golux.Com> on 2004/03/24 22:50:45 UTC
more on the perl-framework on windows
specifically what operations need make or nmake? i need to
know so i can provide appropriately-prepared files so it
won't try to run it. this is so i can run it on systems
that don't have a developer environment installed..
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
Re: more on the perl-framework on windows
Posted by Stas Bekman <st...@stason.org>.
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
Re: more on the perl-framework on windows
Posted by Stas Bekman <st...@stason.org>.
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. 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.
__________________________________________________________________
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
Re: more on the perl-framework on windows
Posted by Stas Bekman <st...@stason.org>.
Rodent of Unusual Size wrote:
> Geoffrey Young wrote:
>
>>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?
>
>
> close, but not quite. the apache.exe and apxs(.*) file may be
> in a different location on each machine tested. so what i want to
> be able to do, on a non-msvc-enabled win32 system, is
>
> 1. perl Makefile.PL -apxs wherever-or-omit -httpd c:/path/to/apache.exe
> 2. [restore the perl-framework/c-modules/.../*.so files from a zip]
> 3. perl -whatever-options-are-needed-but-won't-zap-the-.so-files
> 4. perl t/TEST modules/env
>
> whether the [restore] happens before or after #3 above i don't
> care -- i just want to be able to configure the frameworks according
> to the layout on the box being tested, then put the correct .so files
> in place, and then be able to run the tests. WITHOUT it trying to be
> smart and rebuild what doesn't need to be rebuilt, using tools that
> aren't available.
>
> frustrated? o yeah.. i can't trace and follow all the byways of how
> it figures out what it wants to do, not in the time available. i've
> spent a couple of weeks fighting with this now, and frustration is
> about all i've gotten out of it. :-(
>
> stas, can we get together on irc on this one? i really need to bring
> this to a state i can use asap. i'm rous on irc.freenode.net..
that's what i came up with so far on the irc:
so here is what i suggest as a quick workaround
- you build things on your machine as before now you copy the whole project
into a separate directory and move to work there (so that you don't mess with
the source repository)
- next you do:
mkdir so-modules
cp -r c-modules/*/.lib/*.so so-modules
so now they won't get nuked
- next you need to tell a-t where to find them
so you want to modify t/conf/extra.conf.in to add
LoadModule call for each of these modules
e.g. just throw them into t/conf/cmodules.conf.in
- now hide c-modules so that on the target machine it won't try to build it again
mv c-modules c-modules.bak
- now tar the package and ship it
- on the target machine it should just worl
of course all this can be automated, but first check whether it works for you
--
__________________________________________________________________
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
Re: more on the perl-framework on windows
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Geoffrey Young wrote:
>
> 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?
close, but not quite. the apache.exe and apxs(.*) file may be
in a different location on each machine tested. so what i want to
be able to do, on a non-msvc-enabled win32 system, is
1. perl Makefile.PL -apxs wherever-or-omit -httpd c:/path/to/apache.exe
2. [restore the perl-framework/c-modules/.../*.so files from a zip]
3. perl -whatever-options-are-needed-but-won't-zap-the-.so-files
4. perl t/TEST modules/env
whether the [restore] happens before or after #3 above i don't
care -- i just want to be able to configure the frameworks according
to the layout on the box being tested, then put the correct .so files
in place, and then be able to run the tests. WITHOUT it trying to be
smart and rebuild what doesn't need to be rebuilt, using tools that
aren't available.
frustrated? o yeah.. i can't trace and follow all the byways of how
it figures out what it wants to do, not in the time available. i've
spent a couple of weeks fighting with this now, and frustration is
about all i've gotten out of it. :-(
stas, can we get together on irc on this one? i really need to bring
this to a state i can use asap. i'm rous on irc.freenode.net..
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
Re: more on the perl-framework on windows
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
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
Re: more on the perl-framework on windows
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
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.
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
Re: more on the perl-framework on windows
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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: more on the perl-framework on windows
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
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?
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
Re: more on the perl-framework on windows
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Rodent of Unusual Size wrote:
> Rodent of Unusual Size wrote:
>
>>specifically what operations need make or nmake? i need to
>>know so i can provide appropriately-prepared files so it
>>won't try to run it. this is so i can run it on systems
>>that don't have a developer environment installed..
>
>
> let me put this another way: after running -stop, -clean, and
> -config, the next test run seems to invoke apxs -- which fails
> on a system that doesn't have a make tool. exactly what is
> apxs being invoked to do, and why, and what can i do to give
> the framework what it wants so it won't call apxs?
apxs is not required to run Apache-Test or the perl-framework. it is
required to build any supporting *.c modules, though.
anyway, in the following dialog I removed the apxs binary for that apache
install.
[geoff@jib perl-framework]$ perl Makefile.PL -httpd
/apache/1.3/static/perl-5.8.3/bin/httpd
[geoff@jib perl-framework]$ t/TEST -conf
[warning] cleaning out current configuration
[warning] cannot build c-modules without apxs
[warning] reconfiguration done
[geoff@jib perl-framework]$ t/TEST
/apache/1.3/static/perl-5.8.3/bin/httpd -d /src/httpd-test/perl-framework/t
-f /src/httpd-test/perl-framework/t/conf/httpd.conf -D APACHE1 -D
PERL_USEITHREADS
using Apache/1.3.30-dev
...
t/apache/acceptpathinfo....skipped
all skipped: apache version 2 required, this is version 1
t/apache/byterange.........ok
t/apache/chunkinput........skipped
all skipped: no apxs configured
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.
HTH
--Geoff
Re: more on the perl-framework on windows
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Rodent of Unusual Size wrote:
> specifically what operations need make or nmake? i need to
> know so i can provide appropriately-prepared files so it
> won't try to run it. this is so i can run it on systems
> that don't have a developer environment installed..
let me put this another way: after running -stop, -clean, and
-config, the next test run seems to invoke apxs -- which fails
on a system that doesn't have a make tool. exactly what is
apxs being invoked to do, and why, and what can i do to give
the framework what it wants so it won't call apxs?
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"