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 Markus Wichitill <ma...@gmx.de> on 2004/07/02 10:53:31 UTC

Trying to test current apreq2 CVS

Hi,

I tried to compile the latest apreq2 CVS on Linux to test $upload->fh/size.

First I tried to compile it for mod_perl 1.99_14 (Apache 2.0.50 Worker, Perl
5.8.3), which failed since that version doesn't contain the required
modperl_common_util.h. Maybe that's correct, but I thought I'll mention it
since the docs still say that _09 is required.

So I compiled the current mod_perl CVS first, which copied
modperl_common_util.h into apache2/include. However only after I manually
copied modperl_common_types.h into apache2/include did apreq's Perl glue
compile and test ok.

When I try to upload a file in my webapp, I get "[error] Can't locate
auto/Apache/Request/upload.al in @INC" though. I don't think I ever saw any
of those .al files with MP.

BTW, does the APR::PerlIO-based $upload->fh require Perl 5.8?

Re: Trying to test current apreq2 CVS

Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
[...]
>>BTW, does the APR::PerlIO-based $upload->fh require Perl 5.8?
> 
> 
> Don't know how that works- Stas?

The apr_file_t => GLOB{IO} filehandle conversion should work with 5.6 and 5.8 
I believe.

APR::PerlIO works only with 5.8.x build with:

perl -V:useperlio
useperlio='define';

But can also be checked dynamically doing:

   use APR::PerlIO ();
   die "This Perl build doesn't support PerlIO layers"
       unless APR::PerlIO::PERLIO_LAYERS_ARE_ENABLED;

There is the manpage:
http://perl.apache.org/docs/2.0/api/APR/PerlIO.html#APR__PerlIO__PERLIO_LAYERS_ARE_ENABLED

-- 
__________________________________________________________________
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: Trying to test current apreq2 CVS

Posted by Markus Wichitill <ma...@gmx.de>.
>> BTW, Image::Info expected a passed filehandle to be a reference, if
>> it's a *Apache::Upload::FH typeglob (?) as now, it's wrongly treated
>> as a filename. In apreq1 it's a Apache::Upload=GLOB() ref. Maybe this
>> is Image::Info's problem, or maybe other modules work the same and it
>> couldn't hurt to turn it into a ref in apreq2, too, I don't know.

> Oops- please see if the following patch helps:

Looks good.

Re: Trying to test current apreq2 CVS

Posted by Markus Wichitill <ma...@gmx.de>.
>> After adding the apache\bin dir to PATH, there's plenty of other test
>> failures, I'll look into that tomorrow.
> This was the same apache\bin that corresponded to
> MP_AP_PREFIX at the 'perl Makefile.PL' stage?

Yes.

> Can you post the results of the failures?

Steve Hay beat me to it, same crashing server in t\filter\in_init_basic.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: Trying to test current apreq2 CVS

Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
[...]
> That's a good point - what about the following, which
> should also include Marcus' case of using MP_APXS instead

+1, but the style is not right.

> +    if (Apache::TestConfig::WIN32) {
> +        my $ap_bindir = $build->apr_bindir();
> +        if (! $ap_bindir) {
> +            $ap_bindir = $build->{MP_AP_PREFIX} ?
> +              File::Spec->catdir($build->{MP_AP_PREFIX}, 'bin') : '';
> +        }

and may be it's easier to read it as:

my $ap_bindir = $build->apr_bindir() || '';
unless ($ap_bindir) {
     $ap_bindir = File::Spec->catdir($build->{MP_AP_PREFIX}, 'bin')
         if $build->{MP_AP_PREFIX};
}

> If apr was put into a different directory than
> apache.exe, then I think this is still OK (assuming
> apr_bindir() is successful), as it's really the
> apr dlls that are needed.

OK

>>BTW, env is not needed for win32?
> 
> 
> No ... Even moreso, if I remember correctly, leaving
> it in on Win32 confused some commands in the build,
> which is why it was taken out for Win32.

Got it, thanks. if there was a comment there, I won't have asked... 
hint, hint :)


-- 
__________________________________________________________________
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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: Trying to test current apreq2 CVS

Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Wed, 14 Jul 2004, Stas Bekman wrote:

> doh! I forgot to send it :)

:)

> Randy Kobes wrote:
> > On Wed, 14 Jul 2004, Stas Bekman wrote:
> >
> >
> >>Markus Wichitill wrote:
> >>
> >>>>Adding MP_AP_PREFIX/bin
> >>>>to your PATH is the simplest approach to this (I'll have
> >>>>to see about doing this automatically for the tests).
> >>>
> >>>How about this?
> >>
> >>I'm not sure what is it for, too much context removed, but
> >>I guess Randy knows what is it about.
> >
> >
> > It comes about because, when running the tests, Apache
> > may need certain external dlls in the Apache bin/ directory.
> > The PATH is used to search for these dlls.
>
> Sure :)
>
> > What about the following?
[ .. ]
> If you are sure that that's always be the case then, that's fine, but it
> should be done explicitly for windows then. Since this could be totally
> incorrect in the general case should we try to use $ap_bindir later on.
> So I'd rather see:
>
>      my $preamble;
>      if (Apache::TestConfig::WIN32) {
>          my $ap_bindir = File::Spec->catdir($build->{MP_AP_PREFIX}, 'bin');
>          $preamble = <<EOF;
> PATH = \$(PATH);$ap_bindir
> EOF
>      }
>      else {
>          my $env = Apache::TestConfig->passenv_makestr();
>          $preamble = <<EOF;
> PASSENV = $env
> EOF
>      }

That's a good point - what about the following, which
should also include Marcus' case of using MP_APXS instead
of MP_AP_PREFIX when building mp2:
======================================================
Index: Makefile.PL
===================================================================
RCS file: /home/cvs/modperl-2.0/Makefile.PL,v
retrieving revision 1.143
diff -u -r1.143 Makefile.PL
--- Makefile.PL	5 Jul 2004 22:02:42 -0000	1.143
+++ Makefile.PL	15 Jul 2004 05:11:18 -0000
@@ -597,12 +597,23 @@

 sub MY::test {

-    my $env = Apache::TestConfig->passenv_makestr();
-
-    my $preamble = Apache::TestConfig::WIN32 ? "" : <<EOF;
+    my $preamble;
+    if (Apache::TestConfig::WIN32) {
+        my $ap_bindir = $build->apr_bindir();
+        if (! $ap_bindir) {
+            $ap_bindir = $build->{MP_AP_PREFIX} ?
+              File::Spec->catdir($build->{MP_AP_PREFIX}, 'bin') : '';
+        }
+        $preamble = <<EOF;
+PATH = \$(PATH);$ap_bindir
+EOF
+    }
+    else {
+        my $env = Apache::TestConfig->passenv_makestr();
+        $preamble = <<EOF;
 PASSENV = $env
 EOF
-
+    }
     return $preamble . <<'EOF';
 TEST_VERBOSE = 0
 TEST_FILES =

=======================================================

If apr was put into a different directory than
apache.exe, then I think this is still OK (assuming
apr_bindir() is successful), as it's really the
apr dlls that are needed.

> BTW, env is not needed for win32?

No ... Even moreso, if I remember correctly, leaving
it in on Win32 confused some commands in the build,
which is why it was taken out for Win32.

-- 
best regards,
randy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: Trying to test current apreq2 CVS

Posted by Stas Bekman <st...@stason.org>.
doh! I forgot to send it :)

Randy Kobes wrote:
> On Wed, 14 Jul 2004, Stas Bekman wrote:
> 
> 
>>Markus Wichitill wrote:
>>
>>>>Adding MP_AP_PREFIX/bin
>>>>to your PATH is the simplest approach to this (I'll have
>>>>to see about doing this automatically for the tests).
>>>
>>>How about this?
>>
>>I'm not sure what is it for, too much context removed, but
>>I guess Randy knows what is it about.
> 
> 
> It comes about because, when running the tests, Apache
> may need certain external dlls in the Apache bin/ directory.
> The PATH is used to search for these dlls.

Sure :)

> What about the following?
> ======================================================
> Index: Makefile.PL
> ===================================================================
> RCS file: /home/cvs/modperl-2.0/Makefile.PL,v
> retrieving revision 1.143
> diff -u -r1.143 Makefile.PL
> --- Makefile.PL	5 Jul 2004 22:02:42 -0000	1.143
> +++ Makefile.PL	15 Jul 2004 01:22:50 -0000
> @@ -598,8 +598,13 @@
>  sub MY::test {
> 
>      my $env = Apache::TestConfig->passenv_makestr();
> +    my $ap_bindir = File::Spec->catdir($build->{MP_AP_PREFIX}, 'bin');

If you are sure that that's always be the case then, that's fine, but it 
should be done explicitly for windows then. Since this could be totally 
incorrect in the general case should we try to use $ap_bindir later on. 
So I'd rather see:

     my $preamble;
     if (Apache::TestConfig::WIN32) {
         my $ap_bindir = File::Spec->catdir($build->{MP_AP_PREFIX}, 'bin');
         $preamble = <<EOF;
PATH = \$(PATH);$ap_bindir
EOF
     }
     else {
         my $env = Apache::TestConfig->passenv_makestr();
         $preamble = <<EOF;
PASSENV = $env
EOF
     }

BTW, env is not needed for win32?


-- 
__________________________________________________________________
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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: Trying to test current apreq2 CVS

Posted by Stas Bekman <st...@stason.org>.
Markus Wichitill wrote:
>> It comes about because, when running the tests, Apache
>> may need certain external dlls in the Apache bin/ directory.
>> The PATH is used to search for these dlls.
> 
> 
>> What about the following?
>> +    my $ap_bindir = File::Spec->catdir($build->{MP_AP_PREFIX}, 'bin');
> 
> 
> That doesn't work with "perl Makefile.PL 
> MP_APXS=blah\apache2\bin\apxs.bat", that's why I used $build->apr_bindir().
> 
> If this is about APR possibly being installed outside of the Apache 
> directory (?), I guess we have to include both paths.

That's right, which is quite often the case with packages on unix distros.

May be we need to start working on the equivalent ap_bindir() which will 
search only for apxs and/or httpd?

-- 
__________________________________________________________________
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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: Trying to test current apreq2 CVS

Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:

> No, I wasn't thinking of that possibility; I just thought
> MP_AP_PREFIX would be simpler, but I forgot about using
> MP_APXS instead. What about the following - it tries
> both, and if neither are defined, it give up.
> ===============================================================
> Index: Makefile.PL
> ===================================================================
> RCS file: /home/cvs/modperl-2.0/Makefile.PL,v
> retrieving revision 1.143
> diff -u -r1.143 Makefile.PL
> --- Makefile.PL	5 Jul 2004 22:02:42 -0000	1.143
> +++ Makefile.PL	15 Jul 2004 03:56:21 -0000
> @@ -598,8 +598,17 @@
>  sub MY::test {
> 
>      my $env = Apache::TestConfig->passenv_makestr();
> +    my $ap_bindir = $build->apr_bindir();
> +    if (! $ap_bindir) {
> +        $ap_bindir = $build->{MP_AP_PREFIX} ?
> +        File::Spec->catdir($build->{MP_AP_PREFIX}, 'bin') : '';
> +    }

Add ap_bindir to the Build package?

> -    my $preamble = Apache::TestConfig::WIN32 ? "" : <<EOF;
> +    my $preamble = Apache::TestConfig::WIN32
> +        ? <<EOF
> +PATH = \$(PATH);$ap_bindir
> +EOF
> +        : <<EOF;
>  PASSENV = $env
>  EOF

As mentioned in my previous followup, the two preambles have nothing to 
do with each other: one doesn't use $env, the other doesn't use bindir. 
How about making a clear separation as I suggested in the rewritten code?


-- 
__________________________________________________________________
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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: Trying to test current apreq2 CVS

Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Thu, 15 Jul 2004, Markus Wichitill wrote:

> > It comes about because, when running the tests, Apache
> > may need certain external dlls in the Apache bin/ directory.
> > The PATH is used to search for these dlls.
>
> > What about the following?
> > +    my $ap_bindir = File::Spec->catdir($build->{MP_AP_PREFIX}, 'bin');
>
> That doesn't work with "perl Makefile.PL
> MP_APXS=blah\apache2\bin\apxs.bat", that's why I used
> $build->apr_bindir().
>
> If this is about APR possibly being installed outside of the Apache
> directory (?), I guess we have to include both paths.

No, I wasn't thinking of that possibility; I just thought
MP_AP_PREFIX would be simpler, but I forgot about using
MP_APXS instead. What about the following - it tries
both, and if neither are defined, it give up.
===============================================================
Index: Makefile.PL
===================================================================
RCS file: /home/cvs/modperl-2.0/Makefile.PL,v
retrieving revision 1.143
diff -u -r1.143 Makefile.PL
--- Makefile.PL	5 Jul 2004 22:02:42 -0000	1.143
+++ Makefile.PL	15 Jul 2004 03:56:21 -0000
@@ -598,8 +598,17 @@
 sub MY::test {

     my $env = Apache::TestConfig->passenv_makestr();
+    my $ap_bindir = $build->apr_bindir();
+    if (! $ap_bindir) {
+        $ap_bindir = $build->{MP_AP_PREFIX} ?
+        File::Spec->catdir($build->{MP_AP_PREFIX}, 'bin') : '';
+    }

-    my $preamble = Apache::TestConfig::WIN32 ? "" : <<EOF;
+    my $preamble = Apache::TestConfig::WIN32
+        ? <<EOF
+PATH = \$(PATH);$ap_bindir
+EOF
+        : <<EOF;
 PASSENV = $env
 EOF

===============================================================

-- 
best regards,
randy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: Trying to test current apreq2 CVS

Posted by Markus Wichitill <ma...@gmx.de>.
> It comes about because, when running the tests, Apache
> may need certain external dlls in the Apache bin/ directory.
> The PATH is used to search for these dlls.

> What about the following?
> +    my $ap_bindir = File::Spec->catdir($build->{MP_AP_PREFIX}, 'bin');

That doesn't work with "perl Makefile.PL MP_APXS=blah\apache2\bin\apxs.bat", 
that's why I used $build->apr_bindir().

If this is about APR possibly being installed outside of the Apache 
directory (?), I guess we have to include both paths.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: Trying to test current apreq2 CVS

Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Wed, 14 Jul 2004, Stas Bekman wrote:

> Markus Wichitill wrote:
> >>Adding MP_AP_PREFIX/bin
> >>to your PATH is the simplest approach to this (I'll have
> >>to see about doing this automatically for the tests).
> >
> > How about this?
>
> I'm not sure what is it for, too much context removed, but
> I guess Randy knows what is it about.

It comes about because, when running the tests, Apache
may need certain external dlls in the Apache bin/ directory.
The PATH is used to search for these dlls.

> I have only one
> comment regard to code below
>
> > Index: Makefile.PL
> > ===================================================================
> > RCS file: /home/cvspublic/modperl-2.0/Makefile.PL,v
> > retrieving revision 1.143
> > diff -u -r1.143 Makefile.PL
> > --- Makefile.PL	5 Jul 2004 22:02:42 -0000	1.143
> > +++ Makefile.PL	14 Jul 2004 21:55:20 -0000
> > @@ -597,9 +597,14 @@
> >
> >  sub MY::test {
> >
> > +    my $apr_bindir = $build->apr_bindir();
>
> it's not guaranteed that $build->apr_bindir() will return a defined
> value, so it's better to:
>
>   my $apr_bindir = $build->apr_bindir() || '';
>
> if you later use it in the string:
>
> > -    my $preamble = Apache::TestConfig::WIN32 ? "" : <<EOF;
> > +    my $preamble = Apache::TestConfig::WIN32
> > +      ? <<EOF
> > +PATH = \$(PATH);$apr_bindir
> > +EOF
> > +      : <<EOF;
> >  PASSENV = $env
> >  EOF

What about the following?
======================================================
Index: Makefile.PL
===================================================================
RCS file: /home/cvs/modperl-2.0/Makefile.PL,v
retrieving revision 1.143
diff -u -r1.143 Makefile.PL
--- Makefile.PL	5 Jul 2004 22:02:42 -0000	1.143
+++ Makefile.PL	15 Jul 2004 01:22:50 -0000
@@ -598,8 +598,13 @@
 sub MY::test {

     my $env = Apache::TestConfig->passenv_makestr();
+    my $ap_bindir = File::Spec->catdir($build->{MP_AP_PREFIX}, 'bin');

-    my $preamble = Apache::TestConfig::WIN32 ? "" : <<EOF;
+    my $preamble = Apache::TestConfig::WIN32
+        ? <<EOF
+PATH = \$(PATH);$ap_bindir
+EOF
+        : <<EOF;
 PASSENV = $env
 EOF

===============================================================

-- 
best regards,
randy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: Trying to test current apreq2 CVS

Posted by Stas Bekman <st...@stason.org>.
Markus Wichitill wrote:
>>Adding MP_AP_PREFIX/bin
>>to your PATH is the simplest approach to this (I'll have
>>to see about doing this automatically for the tests).
> 
> 
> How about this?

I'm not sure what is it for, too much context removed, but I guess Randy 
knows what is it about. I have only one comment regard to code below:

> Index: Makefile.PL
> ===================================================================
> RCS file: /home/cvspublic/modperl-2.0/Makefile.PL,v
> retrieving revision 1.143
> diff -u -r1.143 Makefile.PL
> --- Makefile.PL	5 Jul 2004 22:02:42 -0000	1.143
> +++ Makefile.PL	14 Jul 2004 21:55:20 -0000
> @@ -597,9 +597,14 @@
> 
>  sub MY::test {
> 
> +    my $apr_bindir = $build->apr_bindir();

it's not guaranteed that $build->apr_bindir() will return a defined 
value, so it's better to:

  my $apr_bindir = $build->apr_bindir() || '';

if you later use it in the string:

> -    my $preamble = Apache::TestConfig::WIN32 ? "" : <<EOF;
> +    my $preamble = Apache::TestConfig::WIN32
> +      ? <<EOF
> +PATH = \$(PATH);$apr_bindir
> +EOF
> +      : <<EOF;
>  PASSENV = $env
>  EOF
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org


-- 
__________________________________________________________________
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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: Trying to test current apreq2 CVS

Posted by Markus Wichitill <ma...@gmx.de>.
> Adding MP_AP_PREFIX/bin
> to your PATH is the simplest approach to this (I'll have
> to see about doing this automatically for the tests).

How about this?

Index: Makefile.PL
===================================================================
RCS file: /home/cvspublic/modperl-2.0/Makefile.PL,v
retrieving revision 1.143
diff -u -r1.143 Makefile.PL
--- Makefile.PL	5 Jul 2004 22:02:42 -0000	1.143
+++ Makefile.PL	14 Jul 2004 21:55:20 -0000
@@ -597,9 +597,14 @@

 sub MY::test {

+    my $apr_bindir = $build->apr_bindir();
     my $env = Apache::TestConfig->passenv_makestr();

-    my $preamble = Apache::TestConfig::WIN32 ? "" : <<EOF;
+    my $preamble = Apache::TestConfig::WIN32
+      ? <<EOF
+PATH = \$(PATH);$apr_bindir
+EOF
+      : <<EOF;
 PASSENV = $env
 EOF



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: Trying to test current apreq2 CVS

Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sun, 4 Jul 2004, Markus Wichitill wrote:

> > I assume that it's libapreq2.dll it can't find?
>
> Oops, sorry, I meant libapr.dll. Those names just look too similar,
> especially when they're displayed in annoying popup dialogs.

That's true :) libapr.dll would be needed, as some mod_perl
libs were compiled against it. Adding MP_AP_PREFIX/bin
to your PATH is the simplest approach to this (I'll have
to see about doing this automatically for the tests).

> > so, I think this problem would arise because Apache-Test is
> > trying to enable the mod_apreq.so module that it found in
> > your system httpd.conf, but to do so, it needs libapreq2.dll
> > available.
>
> > If that's correct, I'll have to think about how to fix this
> > generally - in the meantime, if you just want to test
> > mod_perl 2, try one of
> > - commenting out the loading of mod_apreq.so in your system
> > httpd.conf,
> > - adding a
> >     LoadFile "/Path/to/libapreq2.dll"
> > to your system httpd.conf,
> > - adding the path to libapreq2.dll to your PATH environment
> > variable.
>
> After adding the apache\bin dir to PATH, there's plenty of other test
> failures, I'll look into that tomorrow.

This was the same apache\bin that corresponded to
MP_AP_PREFIX at the 'perl Makefile.PL' stage? Can you post
the results of the failures? There is a known issue with the
t/protocol/echo_bbs2 test towards the end of 'nmake test',
but I don't have problems with the tests prior to that.
Thanks.

-- 
best regards,
randy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: Trying to test current apreq2 CVS

Posted by Markus Wichitill <ma...@gmx.de>.
> I assume that it's libapreq2.dll it can't find?

Oops, sorry, I meant libapr.dll. Those names just look too similar,
especially when they're displayed in annoying popup dialogs.

> so, I think this problem would arise because Apache-Test is
> trying to enable the mod_apreq.so module that it found in
> your system httpd.conf, but to do so, it needs libapreq2.dll
> available.

> If that's correct, I'll have to think about how to fix this
> generally - in the meantime, if you just want to test
> mod_perl 2, try one of
> - commenting out the loading of mod_apreq.so in your system
> httpd.conf,
> - adding a
>     LoadFile "/Path/to/libapreq2.dll"
> to your system httpd.conf,
> - adding the path to libapreq2.dll to your PATH environment
> variable.

After adding the apache\bin dir to PATH, there's plenty of other test
failures, I'll look into that tomorrow.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: Trying to test current apreq2 CVS

Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sun, 4 Jul 2004, Markus Wichitill wrote:

> > Sorry about that - in the cvs I was assuming MP_INST_APACHE2
> > was being used. Could you try the following patch against
> > the mod_perl 2 cvs?
>
> Compiles and works ok. But some tests like t\apr-ext\perlio fail, because
> APR.dll can't find libapreq.dll.

I assume that it's libapreq2.dll it can't find? And also,
did you install libapreq2 prior to testing mod_perl 2? If
so, I think this problem would arise because Apache-Test is
trying to enable the mod_apreq.so module that it found in
your system httpd.conf, but to do so, it needs libapreq2.dll
available.

If that's correct, I'll have to think about how to fix this
generally - in the meantime, if you just want to test
mod_perl 2, try one of
- commenting out the loading of mod_apreq.so in your system
httpd.conf,
- adding a
    LoadFile "/Path/to/libapreq2.dll"
to your system httpd.conf,
- adding the path to libapreq2.dll to your PATH environment
variable.

-- 
best regards,
randy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: Trying to test current apreq2 CVS

Posted by Markus Wichitill <ma...@gmx.de>.
> Sorry about that - in the cvs I was assuming MP_INST_APACHE2
> was being used. Could you try the following patch against
> the mod_perl 2 cvs?

Compiles and works ok. But some tests like t\apr-ext\perlio fail, because
APR.dll can't find libapreq.dll.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: Trying to test current apreq2 CVS

Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sun, 4 Jul 2004, Stas Bekman wrote:

> Randy Kobes wrote:
> > [ trimmed apreq-dev from cc list ]
> > On Sun, 4 Jul 2004, Markus Wichitill wrote:
> >
> >
> >>>>C:\A\modperl-2.0\blib\arch\Apache2\auto\aprext\aprext.lib : fatal error
> >>>>LNK1136: invalid or corrupt file
> >>>
> >>>Is this with the current mp2 cvs?
> >>
> >>Yes.
> >>
> >>
> >>>- was aprext.lib built (shortly after building mod_perl.so)?
> >>>- if so, was it put under
> >>>     C:\A\modperl-2.0\blib\arch\Apache2\auto\aprext\
> >>>  If not, can you find where?
> >>
> >>It's built and put under blib\arch\auto\aprext.
> >>
> >>I don't use MP_INST_APACHE2 BTW.
> >
> >
> > Sorry about that - in the cvs I was assuming MP_INST_APACHE2
> > was being used. Could you try the following patch against
> > the mod_perl 2 cvs? I'll also send it to you (privately) as
> > an attachment, in case you have trouble applying it. Thanks.
>
> +1

Thanks, Stas - I just committed this, with the changes noted
below.

> >  aprext:
> > -        cd "$aprext" && \$(MAKE) -f \$(FIRST_MAKEFILE) all \$(PASTHRU)
> > +        cd "$src_dir" && \$(MAKE) -f \$(FIRST_MAKEFILE) all \$(PASTHRU)
>
> BTW, since it's a normal Makefile (not Makefile.foo), why do you need the -f
> ... part? I suppose a copy-n-paste from the src/modules/perl target :)

:) You're right, it's not needed - I removed the -f.

> > Index: lib/ModPerl/BuildOptions.pm
> > ===================================================================
> > RCS file: /home/cvs/modperl-2.0/lib/ModPerl/BuildOptions.pm,v
> > retrieving revision 1.26
> > diff -u -r1.26 BuildOptions.pm
> > --- lib/ModPerl/BuildOptions.pm	4 Mar 2004 06:01:06 -0000	1.26
> > +++ lib/ModPerl/BuildOptions.pm	4 Jul 2004 16:03:05 -0000
> > @@ -226,4 +226,4 @@
> >  GENERATE_XS    0    Generate XS code based on httpd version
> >  LIBNAME        0    Name of the modperl dso library (default is  mod_perl)
> >  COMPAT_1X      0    Compile-time mod_perl 1.0 backcompat (default is  on)
> > -
> > +APR_LIB        0    Lib used to build APR::* on Win32 (default is aprext)
>
> this should go to docs too :)

I'll do that ... Also, in the original, I had MP_APR_LIB
defined to a default of 'aprext' only on Win32 (as it's
presently not used anywhere else). However, in testing it on
unix, Makefile.PL in xs/APR/aprext/ emits a warning about
guessing the name (because MP_APR_LIB is used there to set
the NAME MakeMaker attribute). So I changed things so
MP_APR_LIB has the 'aprext' default on all platforms.

-- 
best regards,
randy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: Trying to test current apreq2 CVS

Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> [ trimmed apreq-dev from cc list ]
> On Sun, 4 Jul 2004, Markus Wichitill wrote:
> 
> 
>>>>C:\A\modperl-2.0\blib\arch\Apache2\auto\aprext\aprext.lib : fatal error
>>>>LNK1136: invalid or corrupt file
>>>
>>>Is this with the current mp2 cvs?
>>
>>Yes.
>>
>>
>>>- was aprext.lib built (shortly after building mod_perl.so)?
>>>- if so, was it put under
>>>     C:\A\modperl-2.0\blib\arch\Apache2\auto\aprext\
>>>  If not, can you find where?
>>
>>It's built and put under blib\arch\auto\aprext.
>>
>>I don't use MP_INST_APACHE2 BTW.
> 
> 
> Sorry about that - in the cvs I was assuming MP_INST_APACHE2
> was being used. Could you try the following patch against
> the mod_perl 2 cvs? I'll also send it to you (privately) as
> an attachment, in case you have trouble applying it. Thanks.

+1

>  aprext:
> -        cd "$aprext" && \$(MAKE) -f \$(FIRST_MAKEFILE) all \$(PASTHRU)
> +        cd "$src_dir" && \$(MAKE) -f \$(FIRST_MAKEFILE) all \$(PASTHRU)

BTW, since it's a normal Makefile (not Makefile.foo), why do you need the -f 
... part? I suppose a copy-n-paste from the src/modules/perl target :)

> Index: lib/ModPerl/BuildOptions.pm
> ===================================================================
> RCS file: /home/cvs/modperl-2.0/lib/ModPerl/BuildOptions.pm,v
> retrieving revision 1.26
> diff -u -r1.26 BuildOptions.pm
> --- lib/ModPerl/BuildOptions.pm	4 Mar 2004 06:01:06 -0000	1.26
> +++ lib/ModPerl/BuildOptions.pm	4 Jul 2004 16:03:05 -0000
> @@ -226,4 +226,4 @@
>  GENERATE_XS    0    Generate XS code based on httpd version
>  LIBNAME        0    Name of the modperl dso library (default is  mod_perl)
>  COMPAT_1X      0    Compile-time mod_perl 1.0 backcompat (default is  on)
> -
> +APR_LIB        0    Lib used to build APR::* on Win32 (default is aprext)

this should go to docs too :)

-- 
__________________________________________________________________
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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: Trying to test current apreq2 CVS

Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
[ trimmed apreq-dev from cc list ]
On Sun, 4 Jul 2004, Markus Wichitill wrote:

> >> C:\A\modperl-2.0\blib\arch\Apache2\auto\aprext\aprext.lib : fatal error
> >> LNK1136: invalid or corrupt file
> > Is this with the current mp2 cvs?
>
> Yes.
>
> > - was aprext.lib built (shortly after building mod_perl.so)?
> > - if so, was it put under
> >      C:\A\modperl-2.0\blib\arch\Apache2\auto\aprext\
> >   If not, can you find where?
>
> It's built and put under blib\arch\auto\aprext.
>
> I don't use MP_INST_APACHE2 BTW.

Sorry about that - in the cvs I was assuming MP_INST_APACHE2
was being used. Could you try the following patch against
the mod_perl 2 cvs? I'll also send it to you (privately) as
an attachment, in case you have trouble applying it. Thanks.
==================================================================
Index: Makefile.PL
===================================================================
RCS file: /home/cvs/modperl-2.0/Makefile.PL,v
retrieving revision 1.141
diff -u -r1.141 Makefile.PL
--- Makefile.PL	30 Jun 2004 22:54:53 -0000	1.141
+++ Makefile.PL	4 Jul 2004 16:03:02 -0000
@@ -151,31 +151,32 @@
     $build->generate_apache2_pm;

     # On Win32, in order to decouple APR::* from mod_perl.so, we
-    # make up a static library aprext.lib of the symbols required from
+    # make up a static library MP_APR_LIB of the symbols required from
     # src/modules/perl/*.c (see xs/APR/aprext/Makefile.PL), and
     # then link APR/APR::* against this library. The reason for
     # this is that, unlike Unix, if we had linked APR/APR::* against
-    # mod_perl.lib, then use of APR/APR::* would demand mod_perl.so
+    # the mod_perl lib, then use of APR/APR::* would demand mod_perl.so
     # be available, even if these symbols are supplied by another
     # loaded library (which is done for unix by APR.so - see
-    # xs/APR/APR/Makefile.PL). This also means we must ensure aprext.lib
-    # is built before any of the APR/APR::* modules (see the aprext
-    # target in the MY::top_targets sub below), as symbols must
-    # get resolved at link time.
+    # xs/APR/APR/Makefile.PL). This also means we must ensure the
+    # MP_APR_LIB lib is built before any of the APR/APR::* modules
+    # (see the aprext target in the MY::top_targets sub below), as
+    # symbols must get resolved at link time.

     if (WIN32()) {
+        require File::Basename;
+        require File::Path;
         #Makefile.PL's in WrapXS/ just need to pass the -e mod_perl.lib test
         #the real mod_perl.lib will be in place when WrapXS/ dll's are
         #actually linked
         # this must also be done for aprext.lib, build in xs/APR/aprext/;
         # we must create a dummy aprext.lib to pass the -e test.
-        require File::Path;
         my $lib1 = "src/modules/perl/$build->{MP_LIBNAME}.lib";
-        my $apr_blib = catdir qw(blib arch Apache2 auto aprext);
+        my $lib2 = $build->mp_apr_lib;
+        my $apr_blib = File::Basename::dirname($lib2);
         unless (-d $apr_blib) {
             File::Path::mkpath($apr_blib) or die "mkdir $apr_blib failed: $!";
         }
-        my $lib2 = catfile $apr_blib, 'aprext.lib';
         foreach my $lib ($lib1, $lib2) {
             unless (-e $lib) {
                 open my $fh, '>', $lib or die "open $lib: $!";
@@ -490,11 +491,19 @@

         # must not import File::Spec functions inside MY, it breaks
         # 5.6.x builds
-        my $aprext = File::Spec->catdir(qw(xs APR aprext));
+        my $from = $build->mp_apr_lib;
+        my $apr_lib = $build->{MP_APR_LIB} . $Config{lib_ext};
+        (my $ap_lib = $build->ap_includedir()) =~ s{include$}{lib};
+        my $to = File::Spec->catfile($ap_lib, $apr_lib);
+        my $src_dir = File::Spec->catdir(qw(xs APR aprext));
         $string .= <<"EOF";

 aprext:
-        cd "$aprext" && \$(MAKE) -f \$(FIRST_MAKEFILE) all \$(PASTHRU)
+        cd "$src_dir" && \$(MAKE) -f \$(FIRST_MAKEFILE) all \$(PASTHRU)
+
+aprext_install:
+        \@\$(MKPATH) "$ap_lib"
+        \$(CP) "$from" "$to"

 EOF
     }
@@ -566,6 +575,8 @@
     my $string = $self->MM::install(@_);
     ModPerl::MM::add_dep(\$string, pure_install => 'modperl_lib_install');
     ModPerl::MM::add_dep(\$string, pure_install => 'modperl_xs_h_install');
+    # ModPerl::MM::add_dep(\$string, pure_install => 'aprext_install')
+    #    if WIN32;

     ModPerl::MM::add_dep(\$string, pure_install => 'nuke_Apache__test')
           if $apache_test_install;
Index: lib/Apache/Build.pm
===================================================================
RCS file: /home/cvs/modperl-2.0/lib/Apache/Build.pm,v
retrieving revision 1.163
diff -u -r1.163 Build.pm
--- lib/Apache/Build.pm	16 Jun 2004 03:55:46 -0000	1.163
+++ lib/Apache/Build.pm	4 Jul 2004 16:03:05 -0000
@@ -703,6 +703,8 @@
         @_,
     }, $class;

+    $self->{MP_APR_LIB} = WIN32 ? 'aprext' : '';
+
     ModPerl::BuildOptions->init($self) if delete $self->{init};

     $self;
@@ -1345,6 +1347,24 @@
 sub modperl_libs {
     my $self = shift;
     my $libs = \&{"modperl_libs_$^O"};
+    return "" unless defined &$libs;
+    $libs->($self);
+}
+
+sub mp_apr_lib_MSWin32 {
+    my $self = shift;
+    # MP_APR_LIB.lib will be installed into MP_AP_PREFIX/lib
+    # for use by 3rd party xs modules
+    my $mp_apr_lib = $self->{MP_APR_LIB};
+    my @dirs = $self->{MP_INST_APACHE2} ?
+        qw(blib arch Apache2 auto) : qw(blib arch auto);
+    return catdir $self->{cwd}, @dirs, $mp_apr_lib, "$mp_apr_lib.lib";
+}
+
+# name of lib used to build APR/APR::*
+sub mp_apr_lib {
+    my $self = shift;
+    my $libs = \&{"mp_apr_lib_$^O"};
     return "" unless defined &$libs;
     $libs->($self);
 }
Index: lib/ModPerl/BuildMM.pm
===================================================================
RCS file: /home/cvs/modperl-2.0/lib/ModPerl/BuildMM.pm,v
retrieving revision 1.16
diff -u -r1.16 BuildMM.pm
--- lib/ModPerl/BuildMM.pm	26 Jun 2004 19:41:53 -0000	1.16
+++ lib/ModPerl/BuildMM.pm	4 Jul 2004 16:03:05 -0000
@@ -81,15 +81,13 @@
     my @libs = ();
     if (Apache::Build::WIN32) {
         # in order to decouple APR/APR::* from mod_perl.so,
-        # link these modules against the static aprext.lib,
-        # rather than mod_perl.lib (which would demand mod_perl.so
+        # link these modules against the static MP_APR_LIB lib,
+        # rather than the mod_perl lib (which would demand mod_perl.so
         # be available). For other modules, use mod_perl.lib as
         # usual. This is done for APR in xs/APR/APR/Makefile.PL.
-        my $aprext = catfile $build->{cwd},
-            qw(blib arch Apache2 auto aprext aprext.lib);
         my $name = $args{NAME};
         if ($name =~ /^APR::\w+$/) {
-            @libs = ($build->apache_libs, $aprext);
+            @libs = ($build->apache_libs, $build->mp_apr_lib);
         }
         else {
             @libs = ($build->apache_libs, $build->modperl_libs);
Index: lib/ModPerl/BuildOptions.pm
===================================================================
RCS file: /home/cvs/modperl-2.0/lib/ModPerl/BuildOptions.pm,v
retrieving revision 1.26
diff -u -r1.26 BuildOptions.pm
--- lib/ModPerl/BuildOptions.pm	4 Mar 2004 06:01:06 -0000	1.26
+++ lib/ModPerl/BuildOptions.pm	4 Jul 2004 16:03:05 -0000
@@ -226,4 +226,4 @@
 GENERATE_XS    0    Generate XS code based on httpd version
 LIBNAME        0    Name of the modperl dso library (default is  mod_perl)
 COMPAT_1X      0    Compile-time mod_perl 1.0 backcompat (default is  on)
-
+APR_LIB        0    Lib used to build APR::* on Win32 (default is aprext)
Index: xs/APR/APR/Makefile.PL
===================================================================
RCS file: /home/cvs/modperl-2.0/xs/APR/APR/Makefile.PL,v
retrieving revision 1.24
diff -u -r1.24 Makefile.PL
--- xs/APR/APR/Makefile.PL	1 Jul 2004 01:42:52 -0000	1.24
+++ xs/APR/APR/Makefile.PL	4 Jul 2004 16:03:05 -0000
@@ -30,11 +30,14 @@
 }

 if (WIN32) {
+    require File::Basename;
     $libs =~ s{/libpath:}{-L}g;
     $libs =~ s{(\w+)\.lib}{-l$1}g;
-    # include the static aprext.lib
-    my $aprext = catdir $build->{cwd}, qw(blib arch Apache2 auto aprext);
-    $libs .= qq{ -L"$aprext" -laprext };
+    # include the static MP_APR_LIB lib
+    my ($lib, $dir, $ext) =
+        File::Basename::fileparse($build->mp_apr_lib, qr{\.lib});
+    $dir =~ s!\\$!!;
+    $libs .= qq{ -L"$dir" -l$lib };
 }

 if (SOLARIS && $libs) {
Index: xs/APR/aprext/Makefile.PL
===================================================================
RCS file: /home/cvs/modperl-2.0/xs/APR/aprext/Makefile.PL,v
retrieving revision 1.3
diff -u -r1.3 Makefile.PL
--- xs/APR/aprext/Makefile.PL	1 Jul 2004 01:42:52 -0000	1.3
+++ xs/APR/aprext/Makefile.PL	4 Jul 2004 16:03:05 -0000
@@ -6,6 +6,8 @@
 require ModPerl::Code;
 use Apache::Build ();

+my $build = ModPerl::BuildMM::build_config();
+
 my $srcdir = '../../../src/modules/perl';
 my @names = ModPerl::Code::src_apr_ext();

@@ -20,7 +22,7 @@
 my @skip = qw(dynamic test);
 push @skip, q{static} unless Apache::Build::WIN32;

-my %args = (NAME          => 'aprext',
+my %args = (NAME          => $build->{MP_APR_LIB},
             VERSION_FROM  => '../APR/APR.pm',
             SKIP          =>  [ @skip ] ,
             LINKTYPE      =>  'static',

==============================================================

-- 
best regards,
randy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: Trying to test current apreq2 CVS

Posted by Markus Wichitill <ma...@gmx.de>.
>> C:\A\modperl-2.0\blib\arch\Apache2\auto\aprext\aprext.lib : fatal error
>> LNK1136: invalid or corrupt file
> Is this with the current mp2 cvs?

Yes.

> - was aprext.lib built (shortly after building mod_perl.so)?
> - if so, was it put under
>      C:\A\modperl-2.0\blib\arch\Apache2\auto\aprext\
>   If not, can you find where?

It's built and put under blib\arch\auto\aprext.

I don't use MP_INST_APACHE2 BTW.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: Trying to test current apreq2 CVS

Posted by Markus Wichitill <ma...@gmx.de>.
>> C:\A\modperl-2.0\blib\arch\Apache2\auto\aprext\aprext.lib : fatal error
>> LNK1136: invalid or corrupt file
> Is this with the current mp2 cvs?

Yes.

> - was aprext.lib built (shortly after building mod_perl.so)?
> - if so, was it put under
>      C:\A\modperl-2.0\blib\arch\Apache2\auto\aprext\
>   If not, can you find where?

It's built and put under blib\arch\auto\aprext.

I don't use MP_INST_APACHE2 BTW.

Re: Trying to test current apreq2 CVS

Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sat, 3 Jul 2004, Markus Wichitill wrote:

[ .. ]
> I'd test on WinXP, too, but I can't get MP2 CVS to compile
> right now. While linking Base64.dll it's stumbling over
> the aprext.lib dummy lib:
>
> C:\A\modperl-2.0\blib\arch\Apache2\auto\aprext\aprext.lib : fatal error
> LNK1136: invalid or corrupt file

Is this with the current mp2 cvs? Before it got to
linking Base64.dll it should have built aprext.lib
(the dummy aprext.lib was created there initially
to satisfy ExtUtils::MakeMaker).

- was aprext.lib built (shortly after building mod_perl.so)?
- if so, was it put under
     C:\A\modperl-2.0\blib\arch\Apache2\auto\aprext\
  If not, can you find where?
Thanks.

-- 
best regards,
randy

Re: Trying to test current apreq2 CVS

Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sat, 3 Jul 2004, Markus Wichitill wrote:

[ .. ]
> I'd test on WinXP, too, but I can't get MP2 CVS to compile
> right now. While linking Base64.dll it's stumbling over
> the aprext.lib dummy lib:
>
> C:\A\modperl-2.0\blib\arch\Apache2\auto\aprext\aprext.lib : fatal error
> LNK1136: invalid or corrupt file

Is this with the current mp2 cvs? Before it got to
linking Base64.dll it should have built aprext.lib
(the dummy aprext.lib was created there initially
to satisfy ExtUtils::MakeMaker).

- was aprext.lib built (shortly after building mod_perl.so)?
- if so, was it put under
     C:\A\modperl-2.0\blib\arch\Apache2\auto\aprext\
  If not, can you find where?
Thanks.

-- 
best regards,
randy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: Trying to test current apreq2 CVS

Posted by Joe Schaefer <jo...@sunstarsys.com>.
Markus Wichitill <ma...@gmx.de> writes:

[...]

> BTW, Image::Info expected a passed filehandle to be a reference, if
> it's a *Apache::Upload::FH typeglob (?) as now, it's wrongly treated
> as a filename. In apreq1 it's a Apache::Upload=GLOB() ref. Maybe this
> is Image::Info's problem, or maybe other modules work the same and it
> couldn't hurt to turn it into a ref in apreq2, too, I don't know.

Oops- please see if the following patch helps:

Index: glue/perl/xsbuilder/Apache/Upload/Upload_pm
===================================================================
RCS file: /home/cvs/httpd-apreq-2/glue/perl/xsbuilder/Apache/Upload/Upload_pm,v
retrieving revision 1.6
diff -u -r1.6 Upload_pm
--- glue/perl/xsbuilder/Apache/Upload/Upload_pm 3 Jul 2004 15:45:53 -0000      1.6
+++ glue/perl/xsbuilder/Apache/Upload/Upload_pm 3 Jul 2004 20:40:48 -0000
@@ -8,9 +8,9 @@
 package Apache::Upload;
 sub fh {
     my $upload = shift;
-    my $fh = do {local *FH};
-    tie *$fh, "Apache::Upload::Brigade", $upload->bb;
-    return $fh;
+
+    tie local (*FH), "Apache::Upload::Brigade", $upload->bb;
+    return *FH{IO};
 }

 package Apache::Upload::Error;



-- 
Joe Schaefer


Re: Trying to test current apreq2 CVS

Posted by Markus Wichitill <ma...@gmx.de>.
> Now committed.  The main user-visible difference
> is that the TIEHANDLE implementation isn't seekable.
> It treats the bucket brigade as a stream, not a file,
> and throws away buckets once their data has been
> transferred into an SV. (The underlying apreq_param_t
> brigade is unaffected, since this the TIEHANDLE
> implementation uses its own internal copy).

> All tests should pass now.

Tests do pass on Linux.

Well, some of the ways I've used apreq1's $upload->fh (e.g. with
Image::Info) involved seeking. But if a fully functional $upload->fh isn't
feasible with the buckets, and as long as $upload->tempname works, I can
live with that.

BTW, Image::Info expected a passed filehandle to be a reference, if it's a
*Apache::Upload::FH typeglob (?) as now, it's wrongly treated as a filename.
In apreq1 it's a Apache::Upload=GLOB() ref. Maybe this is Image::Info's
problem, or maybe other modules work the same and it couldn't hurt to turn
it into a ref in apreq2, too, I don't know. Passing \$upload->fh seems to
work, at least until the point where it complains about the missing SEEK.

I'd test on WinXP, too, but I can't get MP2 CVS to compile right now. While
linking Base64.dll it's stumbling over the aprext.lib dummy lib:

C:\A\modperl-2.0\blib\arch\Apache2\auto\aprext\aprext.lib : fatal error
LNK1136: invalid or corrupt file

Re: Trying to test current apreq2 CVS

Posted by Joe Schaefer <jo...@sunstarsys.com>.
Joe Schaefer <jo...@sunstarsys.com> writes:

[...]

> It's the always-seek-before-read behavior of file buckets
> (and which would mean a per make sense for APR::PerlIO) 
                          ^^^
zealous crop! "performance hit, so it woundn't"

Ciao, folks.
-- 
Joe Schaefer


Re: Trying to test current apreq2 CVS

Posted by Joe Schaefer <jo...@sunstarsys.com>.
I wrote:

> >  Suffice it to say that I've already written a tiny TIEHANDLE API
> > for bucket brigades that passes tests 6 and 7 of request.t.  I'll
> > commit it tomorrow after I've had time to whittle it down a bit.

Now committed.  The main user-visible difference
is that the TIEHANDLE implementation isn't seekable.
It treats the bucket brigade as a stream, not a file, 
and throws away buckets once their data has been 
transferred into an SV. (The underlying apreq_param_t
brigade is unaffected, since this the TIEHANDLE
implementation uses its own internal copy).

All tests should pass now.

-- 
Joe Schaefer


Re: Trying to test current apreq2 CVS

Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
> 
> [...]
> 
> 
>>>(file buckets don't buffer file IO, and they always perform a seek
>>>before every file-read operation).
> 
> 
> [...]
> 
> 
>>APR::PerlIO gives you an access to the filehandle. It can't know
>>what's kind of buckets (if at all) are used behind the apr_file_t
>>front, if that's what you were suggesting. 
> 
> 
> It's the always-seek-before-read behavior of file buckets
> (and which would mean a per make sense for APR::PerlIO) which
> makes them so nice.  You can have multiple brigades that
> contain different file buckets *which are all on the same 
> apr_file_t*, but a read on any of those buckets will not 
> corrupt the data in any other bucket.  This is the sort
> of semantics we've always been missing (no, dup(2) doesn't
> achieve this because duped file descriptors always share 
> the same seek pointer).

I don't think this is possible at all, since all you get is a native os 
filehandle.

> Sorry I don't have time to say more about this now, I'm
> off to the Marlins game.  Suffice it to say that I've
> already written a tiny TIEHANDLE API for bucket brigades
> that passes tests 6 and 7 of request.t.  I'll commit it
> tomorrow after I've had time to whittle it down a bit.

Cool

-- 
__________________________________________________________________
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: Trying to test current apreq2 CVS

Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:

[...]

> > (file buckets don't buffer file IO, and they always perform a seek
> > before every file-read operation).

[...]

> APR::PerlIO gives you an access to the filehandle. It can't know
> what's kind of buckets (if at all) are used behind the apr_file_t
> front, if that's what you were suggesting. 

It's the always-seek-before-read behavior of file buckets
(and which would mean a per make sense for APR::PerlIO) which
makes them so nice.  You can have multiple brigades that
contain different file buckets *which are all on the same 
apr_file_t*, but a read on any of those buckets will not 
corrupt the data in any other bucket.  This is the sort
of semantics we've always been missing (no, dup(2) doesn't
achieve this because duped file descriptors always share 
the same seek pointer).

Sorry I don't have time to say more about this now, I'm
off to the Marlins game.  Suffice it to say that I've
already written a tiny TIEHANDLE API for bucket brigades
that passes tests 6 and 7 of request.t.  I'll commit it
tomorrow after I've had time to whittle it down a bit.

-- 
Joe Schaefer


Re: Trying to test current apreq2 CVS

Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Markus Wichitill <ma...@gmx.de> writes:
> 
> [...]
> 
> 
>>But even without any non-zero offset seeking I didn't have much luck with
>>$upload->fh, though my results are too inconsistent to make a useful report.
>>Usually after something like a single read($upload->fh, $buf, 3) or
>>seek($upload->fh, 0, 0) the tempfile was gone.
> 
> 
> Ok, I've committed a few modifications to the test suite that show
> a few problems with our fh() implementation. This is the reason I've
> been reluctant to downplay bucket brigades, since they are a better 
> solution than filehandles are (file buckets don't buffer file IO, and 
> they always perform a seek before every file-read operation).  Unless 
> APR::PerlIO could be made to behave similarly, IMO maybe we're better off 
> implementing fh() in straight perl, by just opening $upload->tempname()
> (Randy, does Win32 even let you do that)?

APR::PerlIO gives you an access to the filehandle. It can't know what's kind 
of buckets (if at all) are used behind the apr_file_t front, if that's what 
you were suggesting. If not, please be more explicit to what you've meant by 
saying "APR::PerlIO could be made to behave similarly"

-- 
__________________________________________________________________
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: Trying to test current apreq2 CVS

Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 2 Jul 2004, Joe Schaefer wrote:
[ .. ]
> Ok, I've committed a few modifications to the test suite
> that show a few problems with our fh() implementation.
> This is the reason I've been reluctant to downplay bucket
> brigades, since they are a better solution than
> filehandles are (file buckets don't buffer file IO, and
> they always perform a seek before every file-read
> operation).  Unless APR::PerlIO could be made to behave
> similarly, IMO maybe we're better off implementing fh() in
> straight perl, by just opening $upload->tempname() (Randy,
> does Win32 even let you do that)?

I'm not sure Win32 can do that - it probably can, as I don't
think there's a reason in principle why not. Unfortunately,
the current $upload->tempname() needs something extra on
Win32 (the current tempname tests fail in glue/perl) - I'm
currently looking at that.

-- 
best regards,
randy


Re: Trying to test current apreq2 CVS

Posted by Joe Schaefer <jo...@sunstarsys.com>.
Markus Wichitill <ma...@gmx.de> writes:

[...]

> But even without any non-zero offset seeking I didn't have much luck with
> $upload->fh, though my results are too inconsistent to make a useful report.
> Usually after something like a single read($upload->fh, $buf, 3) or
> seek($upload->fh, 0, 0) the tempfile was gone.

Ok, I've committed a few modifications to the test suite that show
a few problems with our fh() implementation. This is the reason I've
been reluctant to downplay bucket brigades, since they are a better 
solution than filehandles are (file buckets don't buffer file IO, and 
they always perform a seek before every file-read operation).  Unless 
APR::PerlIO could be made to behave similarly, IMO maybe we're better off 
implementing fh() in straight perl, by just opening $upload->tempname()
(Randy, does Win32 even let you do that)?


-- 
Joe Schaefer


Re: Trying to test current apreq2 CVS

Posted by Joe Schaefer <jo...@sunstarsys.com>.
Markus Wichitill <ma...@gmx.de> writes:

[...]

> Anyways, problems I've noticed:
> 
> It says $upload->tempname in the docs (and in apreq1), but the actual
> method is called $upload->tempfile, and the messages inside the method
> say $upload->temp_file.

Oops, my mistake.  I've corrected cvs to match the docs.

> But even without any non-zero offset seeking I didn't have much luck with
> $upload->fh, though my results are too inconsistent to make a useful report.
> Usually after something like a single read($upload->fh, $buf, 3) or
> seek($upload->fh, 0, 0) the tempfile was gone.

Please look close into this, or at least be more specific about 
the code that's failing and the perl version you're using.

Thanks!
-- 
Joe Schaefer


Re: Trying to test current apreq2 CVS

Posted by Markus Wichitill <ma...@gmx.de>.
> Apache::Upload is now a separate module in apreq2's current-cvs,
> so you need to use() it to get the Apache::Request::upload() function.

Dang, should've thought of that.

Anyways, problems I've noticed:

It says $upload->tempname in the docs (and in apreq1), but the actual method
is called $upload->tempfile, and the messages inside the method say
$upload->temp_file.

I've already run into the documented problem that PerlIO::APR::seek with a
non-zero offset doesn't work if APR and Perl use different largefile
options. Recompiling Perl and dozens of modules with -Uuselargefiles is no
fun. There isn't by any chance a way to compile Apache with largefiles
support that was added recently?

But even without any non-zero offset seeking I didn't have much luck with
$upload->fh, though my results are too inconsistent to make a useful report.
Usually after something like a single read($upload->fh, $buf, 3) or
seek($upload->fh, 0, 0) the tempfile was gone.

I guess I'll stick to $upload->tempname/file. I suppose the warning about
that method in apreq1 is obsolete now?

Re: Trying to test current apreq2 CVS

Posted by Joe Schaefer <jo...@sunstarsys.com>.
Markus Wichitill <ma...@gmx.de> writes:

[...]

> So I compiled the current mod_perl CVS first, which copied
> modperl_common_util.h into apache2/include. However only after I
> manually copied modperl_common_types.h into apache2/include did
> apreq's Perl glue compile and test ok.

Yes I have to do the same thing with mp2 current cvs. 
2.04-dev will require the next mp2 release 1.99_15.  
I'm sure this will be fixed pretty soon.
 
> When I try to upload a file in my webapp, I get "[error] Can't locate
> auto/Apache/Request/upload.al in @INC" though. I don't think I ever
> saw any of those .al files with MP.

Apache::Upload is now a separate module in apreq2's current-cvs, 
so you need to use() it to get the Apache::Request::upload() function.

> BTW, does the APR::PerlIO-based $upload->fh require Perl 5.8?

Don't know how that works- Stas?

-- 
Joe Schaefer


Re: Trying to test current apreq2 CVS

Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:

> The following patch to the mod_perl 2 cvs sources should
> include modperl_common_types in the list of header files
> to install in apache2/include:

+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: Trying to test current apreq2 CVS

Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:

> The following patch to the mod_perl 2 cvs sources should
> include modperl_common_types in the list of header files
> to install in apache2/include:

+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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: Trying to test current apreq2 CVS

Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 2 Jul 2004, Markus Wichitill wrote:

> Hi,
>
> I tried to compile the latest apreq2 CVS on Linux to test $upload->fh/size.
>
> First I tried to compile it for mod_perl 1.99_14 (Apache
> 2.0.50 Worker, Perl 5.8.3), which failed since that
> version doesn't contain the required
> modperl_common_util.h. Maybe that's correct, but I thought
> I'll mention it since the docs still say that _09 is
> required.
>
> So I compiled the current mod_perl CVS first, which copied
> modperl_common_util.h into apache2/include. However only
> after I manually copied modperl_common_types.h into
> apache2/include did apreq's Perl glue compile and test ok.

The following patch to the mod_perl 2 cvs sources should
include modperl_common_types in the list of header files
to install in apache2/include:
========================================================
Index: lib/ModPerl/Code.pm
===================================================================
RCS file: /home/cvs/modperl-2.0/lib/ModPerl/Code.pm,v
retrieving revision 1.124
diff -u -r1.124 Code.pm
--- lib/ModPerl/Code.pm	28 Jun 2004 02:10:02 -0000	1.124
+++ lib/ModPerl/Code.pm	2 Jul 2004 18:44:28 -0000
@@ -655,7 +655,7 @@
                                         largefiles);
 my @h_names = (@c_names, map { "modperl_$_" } @h_src_names,
                qw(types time apache_includes perl_includes apr_includes
-                  common_includes));
+                  common_includes common_types));
 sub h_files { [map { "$_.h" } @h_names, @g_h_names] }

 sub clean_files {

==================================================================

-- 
best regards,
randy

Re: Trying to test current apreq2 CVS

Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 2 Jul 2004, Markus Wichitill wrote:

> Hi,
>
> I tried to compile the latest apreq2 CVS on Linux to test $upload->fh/size.
>
> First I tried to compile it for mod_perl 1.99_14 (Apache
> 2.0.50 Worker, Perl 5.8.3), which failed since that
> version doesn't contain the required
> modperl_common_util.h. Maybe that's correct, but I thought
> I'll mention it since the docs still say that _09 is
> required.
>
> So I compiled the current mod_perl CVS first, which copied
> modperl_common_util.h into apache2/include. However only
> after I manually copied modperl_common_types.h into
> apache2/include did apreq's Perl glue compile and test ok.

The following patch to the mod_perl 2 cvs sources should
include modperl_common_types in the list of header files
to install in apache2/include:
========================================================
Index: lib/ModPerl/Code.pm
===================================================================
RCS file: /home/cvs/modperl-2.0/lib/ModPerl/Code.pm,v
retrieving revision 1.124
diff -u -r1.124 Code.pm
--- lib/ModPerl/Code.pm	28 Jun 2004 02:10:02 -0000	1.124
+++ lib/ModPerl/Code.pm	2 Jul 2004 18:44:28 -0000
@@ -655,7 +655,7 @@
                                         largefiles);
 my @h_names = (@c_names, map { "modperl_$_" } @h_src_names,
                qw(types time apache_includes perl_includes apr_includes
-                  common_includes));
+                  common_includes common_types));
 sub h_files { [map { "$_.h" } @h_names, @g_h_names] }

 sub clean_files {

==================================================================

-- 
best regards,
randy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org