apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: renaming apr_filetype enum entries
Date Sun, 19 Sep 2004 21:20:59 GMT
Greg Stein wrote:
> On Fri, Sep 17, 2004 at 07:54:10PM -0400, Stas Bekman wrote:
> 
>>As discussed back in June enum names in the apr_filetype_e entry are 
>>polluting the APR_ defines namespace and it's hard to grok what APR_REG 
>>means when it's used in the code. I've finally started to work on these as 
>>I'm finishing the perl glue manpage for the apr_finfo interface.
>>
>>So any objecttions to the s/APR_/APR_FILETYPE_/ rename?
>>
>>In order to support older versions one will need to also provide a compat 
>>layer:
>>
>>#ifndef APR_FILETYPE_NOFILE
>>#define APR_FILETYPE_NOFILE  APR_NOFILE
>>#endif
> 
> 
> I think you have that backwards. Shouldn't it be:
> 
> #define APR_NOFILE APR_FILETYPE_NOFILE
> 
> i.e. the APR_FILETYPE_* macros are canonical and you're grandfathering the
>   other macros

Right, Greg. I've just used these defines in mod_perl, before apr picks 
those and for older versions as well. I meant these will be needed by 
those projects that will want to use the longer name and will require to 
support older libapr.

> And the #ifndef wrappers are not needed. Just define the old names in
> terms of the new.

yes, yes, inside apr they won't be needed. They will be needed inside 
projects supporting more than one apr generation.

>>...
>>>From what I understood, this should be applied only to the HEAD. Is that 
>>correct?
> 
> 
> Yes.
> 
> wrowe commented on the versioning implications of this. To be precise:
> 
> 1) the new symbolic constants would appear in 1.1
> 2) httpd 2.2 (and 2.1) is planned to be built against 1.0
> 3) if mod_perl uses the new names, it needs to be built against 1.1

it doesn't need to be built against 1.1, as we will provide the macros to 
handle 0.9 - 1.1.

> 4) httpd 2.2 (and 2.1) will be able to work just fine with 1.1 without any
>    recompilation being needed, but you may be fighting a battle against
>    people distribution a 2.2/1.0 combo.

But this can be solved inside 2.2 by adding the ifdef-define-endif future 
compatibility blocks as I've posted in my original proposal. So 2.2 will 
transparently work with apr 1.0 and apr 1.1.

> 5) httpd 2.0 uses APR 0.9 (though it might be buildable against 1.0)

again, the same solution as #4 applies.

> Choose your path for mod_perl, but point #4 seems like it will pose
> trouble for your users.

it doesn't have much to do with mod_perl, besides us trying to keep the 
Perl API consistent with C API, so it's easy to move between the two, 
needing to know only one API.

So if that's fine with everybody and now Bill has pulled down his veto, 
the only thing to wait for is the APR_1_1 branch to appear? Any plans for 
that?

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