You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apreq-dev@httpd.apache.org by Joe Schaefer <jo...@sunstarsys.com> on 2005/04/23 23:05:43 UTC
towards a 2.05-dev release
I just rolled a snapshot from trunk:
http://people.apache.org/~joes/libapreq2-2.05.dev.tar.gz
It's still a rough tarball, but please give it a spin.
Here's what I think our goals should be for the 2.05-dev
release
1) document just the 3 renamed Apache2::* modules,
2) index them correctly on CPAN.
IMO the APR::Request::* stuff can stabilize in the 2.06 (non-dev!)
release, so we don't need to document those right now.
I could use some help with the two issues above though,
especially (2).
--
Joe Schaefer
Re: towards a 2.05-dev release
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Joe Schaefer wrote:
>"Philip M. Gollucci" <pg...@p6m7g8.com> writes:
>
>
>
>>Joe Schaefer wrote:
>>
>>
>>>Thanks Philip! I think the problem is that xsbuilder stopped
>>>building APR::Request once I removed the header_in/out stuff
>>>from apreq_module_t. I didn't see that because I had a prior
>>>install of APR::Request.
>>>I just uploaded a newer one, please see if that's fixed now.
>>>
>>>
>>>
>>+1
>>gmake test docs install all work
>>
>>The previous patch for the t/library/error.c does prevent the
>>test from being run. But is it supposed to if my apr is an SVN build?
>>
>>
>
>I think the problem here has to do with strerror(0) not being
>portable. On linux it's "Success", but its probably something
>different for you. If I'm right, this really isn't an apr issue;
>in any case my comment in the commit log about libapr-0 being the
>culprit is certainly wrong.
>
>
>
From the man page for strerror (3) on FBSD
If the error number is not recognized, these functions return an error
message string containing ``Unknown error: '' followed by the error num-
ber in decimal. The strerror() and strerror_r() functions return EINVAL
as a warning. Error numbers recognized by this implementation fall in
the range *0 < errnum < sys_nerr.**
*
--
END
-----------------------------------------------------------------------------
Philip M. Gollucci
Senior Developer - Liquidity Services Inc.
Phone: 202.558.6268 (Direct)
E-Mail: pgollucci@liquidation.com
Web: http://www.liquidation.com
Re: towards a 2.05-dev release
Posted by Joe Schaefer <jo...@sunstarsys.com>.
"Philip M. Gollucci" <pg...@p6m7g8.com> writes:
> Joe Schaefer wrote:
>> Thanks Philip! I think the problem is that xsbuilder stopped
>> building APR::Request once I removed the header_in/out stuff
>> from apreq_module_t. I didn't see that because I had a prior
>> install of APR::Request.
>> I just uploaded a newer one, please see if that's fixed now.
>>
> +1
> gmake test docs install all work
>
> The previous patch for the t/library/error.c does prevent the
> test from being run. But is it supposed to if my apr is an SVN build?
I think the problem here has to do with strerror(0) not being
portable. On linux it's "Success", but its probably something
different for you. If I'm right, this really isn't an apr issue;
in any case my comment in the commit log about libapr-0 being the
culprit is certainly wrong.
--
Joe Schaefer
Re: towards a 2.05-dev release
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Joe Schaefer wrote:
> Thanks Philip! I think the problem is that xsbuilder stopped
> building APR::Request once I removed the header_in/out stuff
> from apreq_module_t. I didn't see that because I had a prior
> install of APR::Request.
>
> I just uploaded a newer one, please see if that's fixed now.
>
+1
gmake test docs install all work
The previous patch for the t/library/error.c does prevent the
test from being run. But is it supposed to if my apr is an SVN build?
ldd httpd
httpd:
libm.so.3 => /lib/libm.so.3 (0x280c9000)
libaprutil-1.so.2 => httpd/lib/libaprutil-1.so.2 (0x280dd000)
libapriconv.so.2 => httpd/lib/libapriconv.so.2 (0x280f4000)
libexpat.so.5 => /usr/local/lib/libexpat.so.5 (0x28104000)
libapr-1.so.2 => httpd/lib/libapr-1.so.2 (0x28122000)
libcrypt.so.2 => /lib/libcrypt.so.2 (0x28148000)
libpthread.so.1 => /usr/lib/libpthread.so.1 (0x28160000)
libc.so.6 => /lib/libc.so.6 (0x28185000)
HTH
--
END
------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 301.254.5198
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Developer / Liquidity Services, Inc.
http://www.liquidityservicesinc.com
Re: towards a 2.05-dev release
Posted by Joe Schaefer <jo...@sunstarsys.com>.
"Philip M. Gollucci" <pg...@p6m7g8.com> writes:
> Randy Kobes wrote:
>> On Sat, 23 Apr 2005, Joe Schaefer wrote:
>>
>>>I just rolled a snapshot from trunk:
>>>
>>> http://people.apache.org/~joes/libapreq2-2.05.dev.tar.gz
>>>
>>>It's still a rough tarball, but please give it a spin.
>> Builds and tests fine for me on Win32 (ActivePerl 811).
> -1
>
> 95% of the tests in the perl glue fail for me with errors like:
Thanks Philip! I think the problem is that xsbuilder stopped
building APR::Request once I removed the header_in/out stuff
from apreq_module_t. I didn't see that because I had a prior
install of APR::Request.
I just uploaded a newer one, please see if that's fixed now.
--
Joe Schaefer
Re: towards a 2.05-dev release
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Randy Kobes wrote:
> On Sat, 23 Apr 2005, Joe Schaefer wrote:
>
>
>>I just rolled a snapshot from trunk:
>>
>> http://people.apache.org/~joes/libapreq2-2.05.dev.tar.gz
>>
>>It's still a rough tarball, but please give it a spin.
>
>
> Builds and tests fine for me on Win32 (ActivePerl 811).
-1
95% of the tests in the perl glue fail for me with errors like:
[Sun Apr 24 05:57:35 2005] [error] [client 127.0.0.1] failed to resolve
handler `TestAPI::cookie': Can't locate APR/Request.pm in @INC (@INC
contains:
/usr/home/pgollucci/dev/src/libapreq2-2.05-dev/glue/perl/blib/lib
/usr/home/pgollucci/dev/src/libapreq2-2.05-dev/glue/perl/blib/arch
/usr/home/pgollucci/dev/src/libapreq2-2.05-dev/glue/perl/t/response
/usr/home/pgollucci/dev/src/libapreq2-2.05-dev/glue/perl/t
/home/pgollucci/dev/inst/5.9.3_2.1.5-dev_prefork/perl/lib/mach
/home/pgollucci/dev/inst/5.9.3_2.1.5-dev_prefork/perl/lib
/home/pgollucci/dev/inst/5.9.3_2.1.5-dev_prefork/perl/lib/site_perl/mach
/home/pgollucci/dev/inst/5.9.3_2.1.5-dev_prefork/perl/lib/site_perl .)
at
/usr/home/pgollucci/dev/src/libapreq2-2.05-dev/glue/perl/blib/lib/APR/Request/Cookie.pm
line 26.
BEGIN failed--compilation aborted at
/usr/home/pgollucci/dev/src/libapreq2-2.05-dev/glue/perl/blib/lib/APR/Request/Cookie.pm
line 26.
Compilation failed in require at
/usr/home/pgollucci/dev/src/libapreq2-2.05-dev/glue/perl/t/response/TestAPI/cookie.pm
line 9.
BEGIN failed--compilation aborted at
/usr/home/pgollucci/dev/src/libapreq2-2.05-dev/glue/perl/t/response/TestAPI/cookie.pm
line 9.
Compilation failed in require at (eval 3) line 3.
cd libapreq2-2.05-dev/glue/perl
find . -name "Request.pm"
./lib/Apache2/Request.pm
./xsbuilder/APR/Request/Request.pm
./blib/lib/Apache2/Request.pm
Looks like something didn't get built via the xsbuilder ?
Also, though far less important,
t/library/error.c I still get a failure for the APR::SUCCESS test
[Unknown Error Code: 0]
I'm sure the first one is something trivial, but I'm _very_ short on
time this week, so I don't have time to track it down. If someone comes
of with a fix/reason I can give it a quick try after wednesday.
[I did remember to use gmake this time :)]
HTH
END
------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 301.254.5198
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Developer / Liquidity Services, Inc.
http://www.liquidityservicesinc.com
Reinstate bucket_alloc and pool (Re: towards a 2.05-dev release)
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:
[...]
> That works great! I've committed the changes for this,
> and also the associated ones for Win32; let me know
> if something's amiss.
Looks ok to me. The last tweak I want to make
is to reinstate bucket_alloc and pool to apreq_module_t,
because passing in a safe pool looks too complicated
to me. It'd be best if we provided them, and
validated that their lifetimes are ok whenever
someone asks to use a different pool.
Unless someone objects, I'll make this
change and we can focus on getting our
docs cleaned up before moving to release-candidate
mode.
--
Joe Schaefer
Re: towards a 2.05-dev release
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sun, 24 Apr 2005, Joe Schaefer wrote:
> Joe Schaefer <jo...@sunstarsys.com> writes:
>
> [...]
>
> Hmm, thinking about this some more... I think Makefile.am
> is converted to Makefile.in during a ./buildconf run. So
> what you're proposing for unix (creating a Makefile.am.in)
> may not be workable.
>
> How about trying to generate the PREREQ_PM list from
> buildconf? We could modify Makefile.in after buildconf
> executes build/xsbuilder, seeding it with values from
> version_check, eg add to buildconf something like this:
>
> PREREQ_PM=`$perl build/version_check.pl --perl_prereq`
> echo "running cpan prereq fixups" &&
> perl -i -wpe "s/PREREQ_PM/$PREREQ_PM/" Makefile.in
>
>
> and put the string "PREREQ_PM" in Makefile.am. That'd
> work for unix, but I don't know about the win32 build.
That works great! I've committed the changes for this,
and also the associated ones for Win32; let me know
if something's amiss.
--
best regards,
randy
Re: towards a 2.05-dev release
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Joe Schaefer <jo...@sunstarsys.com> writes:
> Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:
[...]
>> For unix, would it work to create a 'Makefile.am.in' (being the
>> current Makefile.am), and then have Makefile.PL create a Makefile.am
>> consisting of $makefile_front, followed by Makefile.am.in, and then
>> run ./configure?
Hmm, thinking about this some more... I think Makefile.am
is converted to Makefile.in during a ./buildconf run. So
what you're proposing for unix (creating a Makefile.am.in)
may not be workable.
How about trying to generate the PREREQ_PM list from
buildconf? We could modify Makefile.in after buildconf
executes build/xsbuilder, seeding it with values from
version_check, eg add to buildconf something like this:
PREREQ_PM=`$perl build/version_check.pl --perl_prereq`
echo "running cpan prereq fixups" &&
perl -i -wpe "s/PREREQ_PM/$PREREQ_PM/" Makefile.in
and put the string "PREREQ_PM" in Makefile.am. That'd
work for unix, but I don't know about the win32 build.
--
Joe Schaefer
Re: towards a 2.05-dev release
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:
[...]
> Upon running 'perl Makefile.PL', $makefile_front is
> available to add to the top of the generated Makefile. For
> unix, would it work to create a 'Makefile.am.in' (being the
> current Makefile.am), and then have Makefile.PL create a
> Makefile.am consisting of $makefile_front, followed by
> Makefile.am.in, and then run ./configure? If so, I'll do
> this, and also do the corresponding thing for Win32.
Definitely worth a shot, +1. Just make
sure the commit log message indicates
when you think you have it all working,
so I can test it out over here.
--
Joe Schaefer
Re: towards a 2.05-dev release
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sat, 23 Apr 2005, Joe Schaefer wrote:
> Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:
>
> > On Sat, 23 Apr 2005, Joe Schaefer wrote:
> > [ ... ]
> >> What about the Makefile foo we talked about
> >> for the cpan client?
> >
> > I suppose one of the issues here is that the top-level
> > Makefile.PL calls ./configure, which then writes the
> > Makefile, whereas CPAN.pm likes to have Makefile generated
> > by ExtUtils::MakeMaker?
>
> Right. IIRC we discussed fudging that by putting some
> comments at the top of the generated Makefile. I left
> some comment space at the top of Makefile.am; would that
> help any?
I forgot about that - you're right, I think that would
be enough to trick CPAN clients into following
prerequisites. At least for CPAN.pm, something like
=======================================================
# MakeMaker Parameters:
# PREREQ_PM => { BAR::FOO=>q[0.12], FOO::BAR=>q[0] }
# --- MakeMaker post_initialize section:
==============================================================
is looked for in the generated Makefile (up to the
"post_initialize" line), and if a PREREQ_PM string
is found, that's used to populate the prerequisities
list. So we could do something like the following
(the patch is longer than it looks, as I redid the
Win32 stuff to also test the prerequsites in the same
way):
==============================================================
Index: Makefile.PL
===================================================================
--- Makefile.PL (revision 164473)
+++ Makefile.PL (working copy)
@@ -8,51 +8,78 @@
use constant PERL_PATH => $Config{perlpath}; # XXX
use constant WIN32 => ($^O =~ /Win32/);
+my %prereqs;
+
sub test_prereq {
- system (PERL_PATH, "build/version_check.pl", @_) == 0
- or die "Please upgrade $_[0] first.\n";
+ my $mod = shift;
+ my $cmd = join " ", PERL_PATH, "build/version_check.pl", $mod;
+ my $response = qx{$cmd};
+ print $response;
+ return if $response =~ / ok$/;
+ $response =~ /unsupported \((\S+) or/;
+ $prereqs{$mod} = $1;
}
test_prereq perl => PERL_PATH;
+my %opts;
+undef @opts{qw(with-apache2-apxs with-apache1-apxs with-apache2-src
+ with-perl with-apache2-httpd
+ with-apr-config with-apu-config apxs)};
if (WIN32) {
- push @ARGV, '--with-perl=' . PERL_PATH;
- my @args = (PERL_PATH, 'win32/Configure.pl', @ARGV);
- print "@args\n";
- system(@args) == 0 or die "system @args failed: $?";
+ undef $opts{'with-apache2'};
}
-else {
- my %opts;
- undef @opts{qw(with-apache2-apxs with-apache1-apxs with-apache2-src
- with-perl with-apache2-httpd
- with-apr-config with-apu-config apxs)};
- my @flags = qw/enable-maintainer-mode enable-perl-glue disable-perl-glue/;
- my %args;
- # grab from @ARGV only the options that we expect
- GetOptions(\%args, (map "$_=s", keys %opts), @flags);
+my @flags = qw/enable-maintainer-mode enable-perl-glue disable-perl-glue/;
+my %args;
+# grab from @ARGV only the options that we expect
+GetOptions(\%args, (map "$_=s", keys %opts), @flags);
- $args{"with-perl"} = PERL_PATH;
- my $opts = "";
- $opts .= "--enable-maintainer-mode " if $args{"enable-maintainer-mode"};
+$args{"with-perl"} = PERL_PATH;
+my $opts = "";
+$opts .= "--enable-maintainer-mode " if $args{"enable-maintainer-mode"};
- unless (exists $args{"disable-perl-glue"}) {
- $opts .= "--enable-perl-glue ";
- test_prereq "mod_perl";
- test_prereq "Apache::Test";
- test_prereq "ExtUtils::MakeMaker";
- test_prereq "ExtUtils::XSBuilder";
- test_prereq "Test::More";
- }
+unless (exists $args{"disable-perl-glue"}) {
+ $opts .= "--enable-perl-glue ";
+ test_prereq "mod_perl";
+ test_prereq "Apache::Test";
+ test_prereq "ExtUtils::MakeMaker";
+ test_prereq "ExtUtils::XSBuilder";
+ test_prereq "Test::More";
+}
- delete @args{@flags};
- $args{"with-apache2-apxs"} = delete $args{apxs}
- if exists $args{apxs} and not exists $args{"with-apache2-apxs"};
+delete @args{@flags};
+$args{"with-apache2-apxs"} = delete $args{apxs}
+ if exists $args{apxs} and not exists $args{"with-apache2-apxs"};
- $args{"with-perl-opts"} = "@ARGV" if @ARGV;
+$args{"with-perl-opts"} = "@ARGV" if @ARGV;
+my @prereqs = map {"$_ => q[$prereqs{$_}]"} keys %prereqs;
+my $prereq_string = '';
+if (@prereqs) {
+ $prereq_string = 'PREREQ_PM => {' . (join ', ', @prereqs) . '}';
+}
+
+my $makefile_front = <<"END";
+# This is a trick to get CPAN clients to follow prerequisites
+# Don't edit this file, edit Makefile.PL instead
+#
+# ANY CHANGES HERE WILL BE LOST
+#
+# $prereq_string
+#
+# --- MakeMaker post_initialize section:
+
+END
+
+if (WIN32) {
+ my @opts = map{qq/--$_="$args{$_}"/} keys %args;
+ my @args = (PERL_PATH, 'win32/Configure.pl', @opts);
+ print "@args\n";
+ system(@args) == 0 or die "system @args failed: $?";
+}
+else {
$opts .= join " ", map {qq/--$_="$args{$_}"/} keys %args;
-
my $cmd = "./configure $opts";
print "$cmd\n";
exec $cmd;
Index: build/version_check.pl
===================================================================
--- build/version_check.pl (revision 164481)
+++ build/version_check.pl (working copy)
@@ -151,8 +151,11 @@
$_ = 0 for @saw[@saw .. $#version]; # ensure @saw has enough entries
for (0.. $#version) {
last if $version[$_] < $saw[$_];
- die <<EOM if $version[$_] > $saw[$_];
+ if ($version[$_] > $saw[$_]) {
+ print <<EOM;
$0 failed: $tool version $saw unsupported ($version or greater is required).
EOM
+ exit;
+ }
}
print "$tool: $saw ok\n";
========================================================================
Upon running 'perl Makefile.PL', $makefile_front is
available to add to the top of the generated Makefile. For
unix, would it work to create a 'Makefile.am.in' (being the
current Makefile.am), and then have Makefile.PL create a
Makefile.am consisting of $makefile_front, followed by
Makefile.am.in, and then run ./configure? If so, I'll do
this, and also do the corresponding thing for Win32.
--
best regards,
randy
Re: towards a 2.05-dev release
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:
> On Sat, 23 Apr 2005, Joe Schaefer wrote:
> [ ... ]
>> What about the Makefile foo we talked about
>> for the cpan client?
>
> I suppose one of the issues here is that the top-level
> Makefile.PL calls ./configure, which then writes the
> Makefile, whereas CPAN.pm likes to have Makefile generated
> by ExtUtils::MakeMaker?
Right. IIRC we discussed fudging that by putting some
comments at the top of the generated Makefile. I left
some comment space at the top of Makefile.am; would that
help any?
--
Joe Schaefer
Re: towards a 2.05-dev release
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sat, 23 Apr 2005, Joe Schaefer wrote:
[ ... ]
> What about the Makefile foo we talked about
> for the cpan client?
I suppose one of the issues here is that the top-level
Makefile.PL calls ./configure, which then writes the
Makefile, whereas CPAN.pm likes to have Makefile generated
by ExtUtils::MakeMaker? That way, in particular, PREREQ_PM
can be populated for handling prerequisites.
What about something like the following? Move all the C
stuff (including configure-related files) into a
subdirectory, and all the perl glue into another. The
top-level Makefile.PL could then take an argument specifying
apxs, as well as building up a PREREQ_PM list of
prerequisites based on the existing version checking done,
and then use ExtUtils::MakeMaker to write out a Makefile.
This Makefile could have as one of it's targets the
"./configure $opts" done by the current Makefile.PL to build
the C lib in the subdirectory, which is then used to build
the perl glue. The "test" and "install" targets would have
to be modified accordingly to include both the relevant C
and Perl bits.
If this sounds worth looking into, I could give it a try; I
have a CPAN module - Math-Cephes - which builds a C library
and then links some Perl glue to it, which is qualitatively
similar (although not as involved) as what's being done
here.
--
best regards,
randy
Re: towards a 2.05-dev release
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:
> On Sat, 23 Apr 2005, Joe Schaefer wrote:
[...]
>> Here's what I think our goals should be for the 2.05-dev
>> release
>>
>> 1) document just the 3 renamed Apache2::* modules,
>> 2) index them correctly on CPAN.
>>
> Related to (1), I see that you've updated the existing docs
> to use Apache2. I've been looking at the docs/tests under
> glue/perl/docs/ - are getting them working something you
> think should be done as soon as possible?
No, I've given up on having doc tests for Apache2::*,
since those modules will always require mp2. I do want
to have the doc tests for most of APR::Request::* though.
But those module docs still need to be written.
> As for (2), there isn't currently an Apache2::Request,
> Apache2::Cookie, nor Apache2::Upload on CPAN, so I think
> that, once the CPAN libapreq2 is not marked as a development
> version, the PAUSE indexer should pick these up, in
> principle. There may be some subtelties with the
> non-conventional directory structure in libapreq2, but PAUSE
> now understands the "provides" field of META.yml, listing
> what is provided by the distribution, which should help.
Cool, thanks. What about the Makefile foo we talked about
for the cpan client?
--
Joe Schaefer
Re: towards a 2.05-dev release
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sat, 23 Apr 2005, Joe Schaefer wrote:
> I just rolled a snapshot from trunk:
>
> http://people.apache.org/~joes/libapreq2-2.05.dev.tar.gz
>
> It's still a rough tarball, but please give it a spin.
Builds and tests fine for me on Win32 (ActivePerl 811).
> Here's what I think our goals should be for the 2.05-dev
> release
>
> 1) document just the 3 renamed Apache2::* modules,
> 2) index them correctly on CPAN.
>
> IMO the APR::Request::* stuff can stabilize in the 2.06 (non-dev!)
> release, so we don't need to document those right now.
>
> I could use some help with the two issues above though,
> especially (2).
Related to (1), I see that you've updated the existing docs
to use Apache2. I've been looking at the docs/tests under
glue/perl/docs/ - are getting them working something you
think should be done as soon as possible? If so, I take it
they should be tested via CGI? And should the Error.pod
and Table.pod in glue/perl/docs/ be similarly updated?
As for (2), there isn't currently an Apache2::Request,
Apache2::Cookie, nor Apache2::Upload on CPAN, so I think
that, once the CPAN libapreq2 is not marked as a development
version, the PAUSE indexer should pick these up, in
principle. There may be some subtelties with the
non-conventional directory structure in libapreq2, but PAUSE
now understands the "provides" field of META.yml, listing
what is provided by the distribution, which should help.
--
best regards,
randy
Re: towards a 2.05-dev release
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Joe Schaefer <jo...@sunstarsys.com> writes:
> I just rolled a snapshot from trunk:
>
> http://people.apache.org/~joes/libapreq2-2.05.dev.tar.gz
>
> It's still a rough tarball, but please give it a spin.
>
> Here's what I think our goals should be for the 2.05-dev
> release
>
> 1) document just the 3 renamed Apache2::* modules,
> 2) index them correctly on CPAN.
>
> IMO the APR::Request::* stuff can stabilize in the 2.06 (non-dev!)
> release, so we don't need to document those right now.
>
> I could use some help with the two issues above though,
> especially (2).
AFAICT all known code issues are resolved, so I'm
moving into doc-writing mode now. If there are
any outstanding patches that folks want to contribute
prior to issuing release candidates, now would be the
time to do that.
Which reminds me, lots of things have changed since 2.04-dev,
so if folks want to add some helpful Q-n-A to FAQ.pod that
would be outstanding. I'm going to focus mainly on the
doxygen stuff as it relates to the perl glue, so I probably
won't have time to update FAQ.pod myself (other than apply
helpful patches).
--
Joe Schaefer
Re: towards a 2.05-dev release
Posted by Bojan Smojver <bo...@rexursive.com>.
On Sat, 2005-04-23 at 17:05 -0400, Joe Schaefer wrote:
> I just rolled a snapshot from trunk:
>
> http://people.apache.org/~joes/libapreq2-2.05.dev.tar.gz
This would actually be:
http://people.apache.org/~joes/libapreq2-2.05-dev.tar.gz
--
Bojan
Re: towards a 2.05-dev release
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Stephen Clouse wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Trunk works better. Now it's down to this:
>
>Failed Test Stat Wstat Total Fail Failed List of Failed
>- -------------------------------------------------------------------------------
>t/apreq/cgi.t 41 41 100.00% 1-41
>t/apreq/request.t 18 1 5.56% 18
>
>This is old news:
>
>[Mon Apr 25 15:30:42 2005] [error] [client 127.0.0.1] Can't load
>'/home/stephenc/devel/external/httpd-apreq-2/glue/perl/t/cgi-bin/../../blib
>/arch/auto/APR/Request/Request.so' for module APR::Request: libapreq2.so.2:
>cannot open shared object file: No such file or directory at
>/usr/lib/perl5/5.8.6/i386-linux/DynaLoader.pm line 230.
>
>Not sure what to make of this, though. Some API changed, perhaps?
>
>[Mon Apr 25 15:30:57 2005] [error] [client 127.0.0.1] Can't locate object method
>"body" via package "APR::Request::Error" at
>/home/stephenc/devel/external/httpd-apreq-2/glue/perl/t/response/TestApReq/request.pm
>line 143.
>
>
This I'm not too sure about yet... I won't have time to try to reproduce
it until
Wed or likely Thursday night.
--
END
-----------------------------------------------------------------------------
Philip M. Gollucci
Senior Developer - Liquidity Services Inc.
Phone: 202.558.6268 (Direct)
E-Mail: pgollucci@liquidation.com
Web: http://www.liquidation.com
Re: towards a 2.05-dev release
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Bojan Smojver <bo...@rexursive.com> writes:
> On Tue, 2005-04-26 at 11:23 -0400, Joe Schaefer wrote:
>
>> No. The external major number is only bumped to "3" (libname is always
>> libapreq2 tho) when compiling against httpd's trunk (2.2 tobe).
>
> This is what I see on my box, compiled against Apache 2.1.3:
Apologies, I should have said "httpd 2.1 or greater".
The difference is the apr major version number.
--
Joe Schaefer
Re: towards a 2.05-dev release
Posted by Bojan Smojver <bo...@rexursive.com>.
On Tue, 2005-04-26 at 11:23 -0400, Joe Schaefer wrote:
> No. The external major number is only bumped to "3" (libname is always
> libapreq2 tho) when compiling against httpd's trunk (2.2 tobe).
This is what I see on my box, compiled against Apache 2.1.3:
----------------------------
libapreq2.a libapreq2.la libapreq2.so libapreq2.so.3
libapreq2.so.3.1.0
----------------------------
However, his error message includes:
----------------------------
for module APR::Request: libapreq2.so.2:
>> cannot open shared object file: No such file or directory at
>> /usr/lib/perl5/5.8.6/i386-linux/DynaLoader.pm line 230
----------------------------
Which makes me think that it's a binary that wants the old library.
--
Bojan
Re: towards a 2.05-dev release
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Bojan Smojver <bo...@rexursive.com> writes:
> Quoting Joe Schaefer <jo...@sunstarsys.com>:
[...]
> Looks like it's looking for the old version of the library. Isn't the
> new one version 3?
No. The external major number is only bumped to "3" (libname is always
libapreq2 tho) when compiling against httpd's trunk (2.2 tobe).
--
Joe Schaefer
Re: towards a 2.05-dev release
Posted by Bojan Smojver <bo...@rexursive.com>.
Quoting Joe Schaefer <jo...@sunstarsys.com>:
>> [Mon Apr 25 15:30:42 2005] [error] [client 127.0.0.1] Can't load
>> '/home/stephenc/devel/external/httpd-apreq-2/glue/perl/t/cgi-bin/../../blib
>> /arch/auto/APR/Request/Request.so' for module APR::Request: libapreq2.so.2:
>> cannot open shared object file: No such file or directory at
>> /usr/lib/perl5/5.8.6/i386-linux/DynaLoader.pm line 230.
>
> The cgi script can't find your local libapreq2.so; I don't know why
> that's happening to you (probably some libtool cruft on your platform).
> I wouldn't worry too much about that bug.
Looks like it's looking for the old version of the library. Isn't the new one
version 3?
--
Bojan
Re: towards a 2.05-dev release
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
>
>>always building as:
>>
>>make clean
>>./buildconf
>
>
> Try
> % ./buildconf --with-perl=/path/to/perl
>
> assuming EU::XSB is installed in that perl's tree.
>
> As always, docpatches are welcome :-).
Ah, right, buildconf doesn't know which perl is later will be used. Thanks
Joe.
--
__________________________________________________________________
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: towards a 2.05-dev release
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> always building as:
>
> make clean
> ./buildconf
Try
% ./buildconf --with-perl=/path/to/perl
assuming EU::XSB is installed in that perl's tree.
As always, docpatches are welcome :-).
--
Joe Schaefer
Re: towards a 2.05-dev release
Posted by Stas Bekman <st...@stason.org>.
>>I just uploaded another snapshot for testing, please give it a try and
>>report back:
>>
>> http://people.apache.org/~joes/libapreq2-2.05-dev.tar.gz
+1
a few issues I've encountered and you may want to look at:
always building as:
make clean
./buildconf
/home/stas/perl/5.8.6-ithread/bin/perl Makefile.PL \
CCFLAGS='-Werror -O0 -g' \
--with-apache2-apxs=/home/stas/httpd/prefork/bin/apxs
make
make test
1) I've ExtUtils::XSBuilder installed, but I get:
build/version_check.pl failed: no version_string found in '' for
'ExtUtils::XSBuilder'.
2) after a successful build:
make distclean:
rm: cannot remove `t/cgi-bin/test_cgi': Not a directory
rm: cannot remove `t/cgi-bin/.libs': Not a directory
make[2]: [test_clean] Error 1 (ignored)
3) I had things messed up at some point, and I've tried:
cd glue/perl && make distclean
cd ../.. && make distclean
and restart from the top I get:
writing...xs//typemap
WARNING no convert code for HASH(0x8f2fc00) -> {typemapid}
WARNING no convert code for HASH(0x8f2fc00) -> {typemapid}
WARNING no convert code for HASH(0x8f31760) -> {typemapid}
WARNING no convert code for HASH(0x8f31760) -> {typemapid}
WARNING no convert code for HASH(0x8f2ace8) -> {typemapid}
WARNING no convert code for HASH(0x8f2ace8) -> {typemapid}
WARNING no convert code for HASH(0x8f2acd0) -> {typemapid}
WARNING no convert code for HASH(0x8f2acd0) -> {typemapid}
WARNING no convert code for HASH(0x8f2ac94) -> {typemapid}
WARNING no convert code for HASH(0x8f2ac94) -> {typemapid}
WARNING no convert code for HASH(0x8f2acdc) -> {typemapid}
WARNING no convert code for HASH(0x8f2acdc) -> {typemapid}
Missing directory ./xsbuilder/tables/APR/Request at
/home/stas/perl/5.8.6-ithread/lib/site_perl/5.8.6/ExtUtils/XSBuilder/ParseSource.pm
line 494.
make[1]: *** [perl/Makefile] Error 2
make[1]: Leaving directory `/tmp/libapreq2-2.05-dev/glue'
make: *** [all-recursive] Error 1
--
__________________________________________________________________
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: towards a 2.05-dev release
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> I just uploaded another snapshot for testing, please give it a try and
> report back:
>
> http://people.apache.org/~joes/libapreq2-2.05-dev.tar.gz
all tests pass for me.
great work all.
--Geoff
Re: towards a 2.05-dev release
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stephen Clouse <st...@theiqgroup.com> writes:
[...]
> t/apreq/cgi.t 41 41 100.00% 1-41
> t/apreq/request.t 18 1 5.56% 18
>
> This is old news:
>
> [Mon Apr 25 15:30:42 2005] [error] [client 127.0.0.1] Can't load
> '/home/stephenc/devel/external/httpd-apreq-2/glue/perl/t/cgi-bin/../../blib
> /arch/auto/APR/Request/Request.so' for module APR::Request: libapreq2.so.2:
> cannot open shared object file: No such file or directory at
> /usr/lib/perl5/5.8.6/i386-linux/DynaLoader.pm line 230.
The cgi script can't find your local libapreq2.so; I don't know why
that's happening to you (probably some libtool cruft on your platform).
I wouldn't worry too much about that bug.
I just uploaded another snapshot for testing, please give it a try and
report back:
http://people.apache.org/~joes/libapreq2-2.05-dev.tar.gz
> Not sure what to make of this, though. Some API changed, perhaps?
>
> [Mon Apr 25 15:30:57 2005] [error] [client 127.0.0.1] Can't locate
> object method "body" via package "APR::Request::Error" at
That one should be fixed; I forgot to require APR::Request::Error in
the tests.
--
Joe Schaefer
Re: towards a 2.05-dev release
Posted by Stephen Clouse <st...@theiqgroup.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Trunk works better. Now it's down to this:
Failed Test Stat Wstat Total Fail Failed List of Failed
- -------------------------------------------------------------------------------
t/apreq/cgi.t 41 41 100.00% 1-41
t/apreq/request.t 18 1 5.56% 18
This is old news:
[Mon Apr 25 15:30:42 2005] [error] [client 127.0.0.1] Can't load
'/home/stephenc/devel/external/httpd-apreq-2/glue/perl/t/cgi-bin/../../blib
/arch/auto/APR/Request/Request.so' for module APR::Request: libapreq2.so.2:
cannot open shared object file: No such file or directory at
/usr/lib/perl5/5.8.6/i386-linux/DynaLoader.pm line 230.
Not sure what to make of this, though. Some API changed, perhaps?
[Mon Apr 25 15:30:57 2005] [error] [client 127.0.0.1] Can't locate object method
"body" via package "APR::Request::Error" at
/home/stephenc/devel/external/httpd-apreq-2/glue/perl/t/response/TestApReq/request.pm
line 143.
- --
Stephen Clouse <st...@theiqgroup.com>
Senior Programmer/DBE, Core Technology Developer
The IQ Group, Inc. <http://www.theiqgroup.com/>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFCbVUTy3uolkRT3A0RAolcAJ9ndVC7vEUFczfBPyg1vWTMBmUhAgCgi6tZ
IWvKQi4iLbz3kK2W9H58568=
=C7Gq
-----END PGP SIGNATURE-----
Re: towards a 2.05-dev release
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Stephen Clouse wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Mon, Apr 25, 2005 at 04:25:43PM -0400, Philip M. Gollucci wrote:
>
>
>>This was fixed recently as I already reported. joes made a new tarball.
>>Download it again from http://people.apache.org/~joes or update your SVN
>>directory.
>>
>>
>
>I quite literally just downloaded the tarball 5 minutes ago. Might want to
>check that....
>
>
Heres the SVN commit:
http://svn.apache.org/viewcvs?rev=164467&view=rev
It fixed it for me.. Don't forget to run ./buildconf again.
FreeBSD6-current/i386
httpd-2.1.5-dev
perl5.9.3
mod_perl1.999.23
http://people.apache.org/~joes/libapreq2-2.05-dev.tar.gz
--
END
-----------------------------------------------------------------------------
Philip M. Gollucci
Senior Developer - Liquidity Services Inc.
Phone: 202.558.6268 (Direct)
E-Mail: pgollucci@liquidation.com
Web: http://www.liquidation.com
Re: towards a 2.05-dev release
Posted by Stephen Clouse <st...@theiqgroup.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, Apr 25, 2005 at 04:25:43PM -0400, Philip M. Gollucci wrote:
> This was fixed recently as I already reported. joes made a new tarball.
> Download it again from http://people.apache.org/~joes or update your SVN
> directory.
I quite literally just downloaded the tarball 5 minutes ago. Might want to
check that....
In the meantime, trying a trunk build now.
- --
Stephen Clouse <st...@theiqgroup.com>
Senior Programmer/DBE, Core Technology Developer
The IQ Group, Inc. <http://www.theiqgroup.com/>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFCbVGGy3uolkRT3A0RAo4IAJ9EWfxuX/cqt/pRnhpkybElq8DQqwCdFwrZ
WChhy74KYtGkZmyD7lEt4Iw=
=IKdl
-----END PGP SIGNATURE-----
Re: towards a 2.05-dev release
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Stephen Clouse wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Perl glue tests are still tripping all over themselves:
>
>Failed Test Stat Wstat Total Fail Failed List of Failed
>- -------------------------------------------------------------------------------
>t/apreq/big_input.t 0 13 21 23 109.52% 1-21
>t/apreq/cgi.t 41 41 100.00% 1-41
>t/apreq/cookie.t 7 7 100.00% 1-7
>t/apreq/inherit.t 4 4 100.00% 1-4
>t/apreq/request.t 0 13 18 35 194.44% 1-18
>t/apreq/upload.t 0 13 20 40 200.00% 1-20
>
>Relevant error log entries:
>
>[Mon Apr 25 15:02:03 2005] [error] [client 127.0.0.1] failed to resolve handler
>`TestApReq::big_input': Can't locate Apache2/Request.pm in @INC (@INC contains:
>
>- From the looks of it, lib/Apache2/* aren't getting copied to blib for whatever
>reason. I assume they were intended to be installed, yes?
>
>[Mon Apr 25 15:02:14 2005] [error] [client 127.0.0.1] Can't load
>'/home/stephenc/devel/external/libapreq2-2.05-dev/glue/perl/t/cgi-bin/../../
>blib/arch/auto/APR/Request/Request.so' for module APR::Request: libapreq2.so.2:
>cannot open shared object file: No such file or directory at
>/usr/lib/perl5/5.8.6/i386-linux/DynaLoader.pm line 230.
>
>I can see a correct LD_RUN_PATH for finding libapreq2.so in the various
>Makefiles, but it doesn't seem to be making it to the test suite.
>
>
This was fixed recently as I already reported. joes made a new tarball.
Download it again from http://people.apache.org/~joes or update your SVN
directory.
--
END
-----------------------------------------------------------------------------
Philip M. Gollucci
Senior Developer - Liquidity Services Inc.
Phone: 202.558.6268 (Direct)
E-Mail: pgollucci@liquidation.com
Web: http://www.liquidation.com
Re: towards a 2.05-dev release
Posted by Stephen Clouse <st...@theiqgroup.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Perl glue tests are still tripping all over themselves:
Failed Test Stat Wstat Total Fail Failed List of Failed
- -------------------------------------------------------------------------------
t/apreq/big_input.t 0 13 21 23 109.52% 1-21
t/apreq/cgi.t 41 41 100.00% 1-41
t/apreq/cookie.t 7 7 100.00% 1-7
t/apreq/inherit.t 4 4 100.00% 1-4
t/apreq/request.t 0 13 18 35 194.44% 1-18
t/apreq/upload.t 0 13 20 40 200.00% 1-20
Relevant error log entries:
[Mon Apr 25 15:02:03 2005] [error] [client 127.0.0.1] failed to resolve handler
`TestApReq::big_input': Can't locate Apache2/Request.pm in @INC (@INC contains:
- From the looks of it, lib/Apache2/* aren't getting copied to blib for whatever
reason. I assume they were intended to be installed, yes?
[Mon Apr 25 15:02:14 2005] [error] [client 127.0.0.1] Can't load
'/home/stephenc/devel/external/libapreq2-2.05-dev/glue/perl/t/cgi-bin/../../
blib/arch/auto/APR/Request/Request.so' for module APR::Request: libapreq2.so.2:
cannot open shared object file: No such file or directory at
/usr/lib/perl5/5.8.6/i386-linux/DynaLoader.pm line 230.
I can see a correct LD_RUN_PATH for finding libapreq2.so in the various
Makefiles, but it doesn't seem to be making it to the test suite.
- --
Stephen Clouse <st...@theiqgroup.com>
Senior Programmer/DBE, Core Technology Developer
The IQ Group, Inc. <http://www.theiqgroup.com/>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFCbU/Jy3uolkRT3A0RAqmuAJ0UI7WaATSvrzPrEVHo75mVY9cnOACfVhsh
kBaGyzJ835TnU+gDhtdCvy4=
=X2/1
-----END PGP SIGNATURE-----