[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: An unexpected effect of new 'deprecated' tags.

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: Thu, 28 Aug 2008 10:25:24 -0700

On Thu, Aug 28, 2008 at 3:18 AM, Philip Martin <philip_at_codematters.co.uk> wrote:
> Julian Foad <julianfoad_at_btopenworld.com> writes:
>
>> In the meantime, I don't know of a better solution than just choosing
>> whether to see all of them or none of them.
>
> None of them in my view.
>
> I still think the implementation is wrong:
>
> /** Macro used to mark deprecated functions.
> *
> * @since New in 1.6.
> */
> #ifndef SVN_DEPRECATED
> #if !defined(SWIGPERL) && !defined(SWIGPYTHON) && !defined(SWIGRUBY)
> #if defined(__GNUC__) && (__GNUC__ >= 4 || (__GNUC__==3 && __GNUC_MINOR__>=1))
> #define SVN_DEPRECATED __attribute__((deprecated))
> #elif defined(_MSC_VER) && _MSC_VER >= 1300
> #define SVN_DEPRECATED __declspec(deprecated)
> #else
> #define SVN_DEPRECATED
> #endif
> #else
> #define SVN_DEPRECATED
> #endif
> #endif
>
> I think it's wrong for these warnings to be enabled by default in 3rd
> party builds. As in my earlier mail I think the code should look
> like:
>
> #ifdef SVN_DEPRECATED_ENABLE
> #define SVN_DEPRECATED magic
> #else
> #define SVN_DEPRECATED
> #endif
>
> and we arrange for configure to define SVN_DEPRECATED_ENABLE in our
> build, although I'd rather not see spurious warnings by default.

+1 to all of the above.

(I'd advocate that the deprecation warnings would only make sense in
maintainer mode, but YMMV.) -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-28 19:25:38 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.