Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Organisation: Radan Computational Ltd., Bath, UK.
Phone: +44 1225 320320   Fax: +44 1225 320311
Web: http://www.radan.com/
Message-ID: <3FB8A1BD.2010301@uk.radan.com>
Date: Mon, 17 Nov 2003 10:23:57 +0000
From: Steve Hay <steve.hay@uk.radan.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
MIME-Version: 1.0
To: Randy Kobes <randy@theoryx5.uwinnipeg.ca>
CC: Joe Schaefer <joe+gmane@sunstarsys.com>, apreq-dev@httpd.apache.org
Subject: Re: [ANN] libapreq2-2.02-dev release candidate #1
References: <m3wua471zd.fsf@sol.sunstarsys.com>
 <m3k7640xh1.fsf@sol.sunstarsys.com> <3FB4A7B9.9080005@uk.radan.com>
 <Pine.LNX.4.56.0311140951090.10901@theoryx5.uwinnipeg.ca>
 <3FB50F0F.3070106@uk.radan.com>
 <Pine.LNX.4.56.0311141223190.13555@theoryx5.uwinnipeg.ca>
In-Reply-To: <Pine.LNX.4.56.0311141223190.13555@theoryx5.uwinnipeg.ca>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Randy Kobes wrote:

>On Fri, 14 Nov 2003, Steve Hay wrote:
>
>  
>
>>Randy Kobes wrote:
>>    
>>
>[ .. ]
>  
>
>>>That is weird ... For one thing,
>>>    nmake perl_test
>>>just does, as you found,
>>>[ ... ]
>>>      
>>>
>>>>       cd C:\Temp\LIBAPR~1.02-\glue\perl
>>>>       NMAKE /nologo test
>>>>
>>>>        
>>>>
>>>so it does a cd into glue/perl and nmakes test from there.
>>>
>>>      
>>>
>>That snippet above is interesting - I hadn't noticed before that it uses
>>the 8.3 name to cd into.  (I used the full name when I cd'd into that
>>directory.)  Just for laughs I tried using the 8.3 name to cd into, and
>>low-and-behold it does fail!
>>
>>In case you've lost the plot at this point, I now have:
>>
>>"nmake perl_test" fails
>>"cd C:\Temp\LIBAPR~1.02-\glue\perl && nmake test" fails
>>"cd C:\Temp\libapreq2-2.02-dev\glue\perl && nmake test" works!
>>    
>>
>
>Very strange - I'm a bit baffled. It's like saying the
>8.3 filename and the full filename aren't equivalent.
>
>I'll look into this more on the weekend. One thing that
>may be happening - do you have multiple libapreq2-2.02***
>directories at the same level? If so, are
>  "cd C:\Temp\LIBAPR~1.02-\glue\perl && nmake test"
>and
>  "cd C:\Temp\libapreq2-2.02-dev\glue\perl && nmake test"
>doing 'nmake test' in the same directory? Perhaps the 8.3
>name puts you into another directory .... This won't solve
>the problem, but at least would explain it.
>
They were definitely going into the same directory.

I can only assume that I hadn't cleaned out everything from the previous 
libapreq installation properly, because I've now rebuilt everything from 
scratch and libapreq-2.02-dev tests OK!

It'll be interesting to see if I run into the same problem again when I 
next try to upgrade libapreq.

>
>[ .. ]
>  
>
>>I just thought of one other weird thing that I've done.
>>I don't know if it is relevant or not, but I don't recall
>>having to do it with libapreq1.  I had to edit the
>>httpd.conf file in my Apache installation directory
>>(C:\apache2) to load mod_perl.  Initially "nmake
>>perl_test"  just bombed out straight away with:
>>
>>    Syntax error on line 185 of
>>C:/Temp/libapreq2-2.02-dev/glue/perl/t/conf/httpd.conf:
>>    Invalid command 'PerlResponseHandler', perhaps mis-spelled or
>>defined by a module not included in the server configuration
>>
>>The  t/conf/httpd.conf file that it wrote contained this:
>>
>>    <IfModule !mod_perl.c>
>>        #unable to locate mod_perl.so (could be a static build)
>>    </IfModule>
>>
>>So I added these lines to my installed Apache conf file:
>>
>>    LoadFile C:/apache2/perl5/bin/perl58.dll
>>    LoadModule perl_module modules/mod_perl.so
>>
>>and tried again.  This time it worked, and the t/conf/httpd.conf file
>>contained this:
>>
>>    <IfModule !mod_perl.c>
>>        LoadFile "C:\apache2\perl5\bin\perl58.dll"
>>    LoadModule perl_module "\Apache2\modules\mod_perl.so"
>>    </IfModule>
>>    
>>
>
>I think this is the expected behaviour - Apache::Test will
>add modules it finds in the system httpd.conf to its
>generated httpd.conf, and, for this particular test,
>mod_perl is needed. You may not have had to do this with
>libapreq1 because you had already loaded mod_perl in the
>corresponding C:\Apache\conf\httpd.conf.
>
Yes, I think you're right - I do load mod_perl in Apache1's conf file 
before testing libapreq1.  I'm sure I didn't use to, though.  Maybe it 
was the switch to Apache::Test that brought about that change.  I think 
I didn't use to have to do that when we were using Apache::test.

- Steve


------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only.  If you have received this message in error or there are any problems, please notify the sender immediately.  The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden.  Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd.  The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.