httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: [apreq-2] does not use apr-config --includes
Date Sun, 17 Aug 2003 06:26:16 GMT
Joe Schaefer wrote:
> Stas Bekman <stas@stason.org> writes:
> 
> [...]
> 
> 
>>2.0.46 is confirmed to have these:
>>
>>/home/stas/httpd/prefork-2.0.46/build> grep BINDIR *
>>config_vars.mk:APR_BINDIR = /home/stas/httpd/prefork-2.0.46/bin
>>config_vars.mk:APU_BINDIR = /home/stas/httpd/prefork-2.0.46/bin
>>
>>So I guess we are all set.
>>
>>However we need to make the requirement coded in ./configure (and
>>Makefile.PL?), it'd be a waste for people to report failures, if the
>>sw can tell them that 2.0.46 is required when they use an older httpd. 
>>Since everything goes through ./configure, it's probably the best
>>place to set the minimal requirement.
> 
> 
> +1.

I'm not quite sure how this is done in .m4 language, but I've added it to the 
todo list, so it won't be forgotten.

>>Also doesn't apreq now depend on the recent changes in apr-tables? or
>>can it work with older apr as well? I haven't tested that.
> 
> 
> No.  They took the httpd optimizations and left out the stuff we 
> needed.  It's no fun in playing with the httpd gang, especially 
> when you're trying to address 7 years of collective apathy toward 
> the table API.

Unfortunately I know what you are experiencing.

> The safest thing to do now would be to dump apr_tables and go back 
> to apreq_tables, which I don't want to do.  The next safest 
> thing would be to override more of the APR::Table API, mainly to 
> disable merge() and provide a safe wrapper for set().

I suppose it depends. If you are satisfied with the current implementation of 
apr_tables and you think that you won't need even more control and flexibility 
in the future, it's probably ok to leave apreq_tables behind. In any case I 
suppose that if you ever need that control you will be able to replace 
apr_tables with apreq_tables, since that won't change the user's API. However 
it's probably safer to use a different class: ApReq::Table since if you change 
the behavior of APR::Table, it'd affect other code which is not expecting this 
change. In the long run it'll give you the flexibility to change the behavior 
without breaking user's code.

I guess you know that already.

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Mime
View raw message