httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: [rfc] a few milestones (was Re: Updating the Website?)
Date Sun, 27 Apr 2003 07:27:19 GMT
Joe Schaefer wrote:
 >>>The next one is within easy reach:
 >>>  2) a basic test framework
 >>>     a) simple unit tests for libapreq.so (the core).
 >>>     b) simple Apache::Test tests for mod_apreq.
 >>>2a is already done (in t/), while 2b needs more work.  I already laid the
 >>>foundation for 2b in glue/perl/.
 >>>Perhaps some of us perl guys can finish that part off while working towards
 >>
 >>Are you talking about applying the XP principles: write tests before
 >>you code? If not won't 3 be a prerequisite for 2b?
 >
 >
 > Personally I think writing tests ASAP is a good idea,
 > but I'm not dogmatic about it.  What I really mean is
 > something a bit more pragmatic: right now there's a c-module
 > test in glue/perl that runs perfectly on my box.  However,
 > to get it to run I have to do all this:
 >
 >   % cd httpd-apreq-2
 >   % ./buildconf && configure --enable-maintainer-mode --with-apache2-apxs=...
 >   % make && make test
 >   % make install
 >   % cd glue/perl
 >   % perl Makefile.PL -apxs ...
 >   % make test
 >
 > At the very least, I'd like to avoid having to install
 > mod_apreq && libapreq.so prior to running the Apache::Test
 > test in glue/perl.

Won't the same approach as used in apreq-1.x work? It doesn't require 'make
install' to build/test the perl glue.

I also don't quite get why do we need c-modules for the perl glue testing.

 >>>  3) Functional APREQ:: packages (perl glue for libapreq).
 >>
 >>It all depends on how rich is the API that we expose to Perl.
 >>If it's quite rick we probably better go with:
 >>http://search.cpan.org/author/GRICHTER/ExtUtils-XSBuilder-0.23/
 >>which is a generalized port of mod_perl 2.0's WrapXS.
 >
 >
 > I've been looking over the modperl XS code recently, and
 > the WrapXS stuff looks really neat.  In any case we'll need
 > to reuse some of the APR typemaps from modperl-2 in order to
 > wrap libapreq.

That typemap is installed systems wide, so it's be automatically included by
ModPerl::MM, which is a replacement for Apache::src.

 >>>  4) Apache::Request / Apache::Cookie ports using
 >>>     the APREQ:: modules.
 >>
 >>I suppose that 3 should be completed first, before 4 can be done.
 >
 >
 > Yeah, but I think 3 + 4 will pretty much happen simultaneously.
 > The hard part will be getting the .xs files working, and
 > I'm expecting those to all be APREQ:: packages.  Apache::Request
 > and Apache::Cookie will probably turn out to just be (tiny) .pm
 > files.

I don't remember when we have discussed this, but won't ApReq:: read better?


__________________________________________________________________
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