On Fri, Sep 24, 2010 at 15:04, Dani Church <dchurch_at_cheri.shyou.org> wrote:
> I'm writing a client that uses the libsvn_client API, and in order to make
> the code as portable as possible, I have been using the minimum API version
> that has the features I need, which in my case is the 1.5 API.
> Unfortunately, that means using deprecated functions which spit out compiler
> warnings.
Before including any svn header, you can do:
#define SVN_DEPRECATED
That will turn off all deprecation warnings. You can also use
-DSVN_DEPRECATED (or similar) to your compiler.
> I wanted to suggest using a preprocessor directive to target a
> codebase to a specific API version, something like the following:
>
> #define USE_SVN_API 105
> #include <svn_client.h>
>
> I figure that could have two effects: first, it wouldn't set SVN_DEPRECATED
> for any functions current as of that API version, and second, it could use
> #pragma GCC poison [1] (or an equivalent for other compilers) to mark any
> functions introduced in a later version as compile errors.
This is an interesting thought. I will note, however, that this would
imply a large set of SVN_DEPRECATED macros for us to use. For example,
SVN_DEPRECATED_1, ... SVN_DEPRECATED_7 to indicate a specific function
was deprecated in 1.1 through 1.7. Those macros would evaluate
differently, based on the USE_SVN_API value. This also implies going
back over all the functions and using the correct DEPRECATED macro on
it (most of the time, the version is in the comments, but not
rigorously).
> Does that make sense? I could go through and write the patch, but I wanted
> to see if there was any buy-in from the community.
That would be a pretty big patch. I see almost 400 deprecated
functions in our headers. Each of those would need to be touched.
I'm not against the concept in general, but would like to see how all
those DEPRECATED macros would turn out, concretely.
Cheers,
-g
Received on 2010-09-24 22:51:38 CEST