apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: renaming apr_filetype enum entries
Date Sun, 19 Sep 2004 13:44:21 GMT
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

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

>...
> 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
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.
5) httpd 2.0 uses APR 0.9 (though it might be buildable against 1.0)

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

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message