Matt Rogers schrieb: > On Friday 10 March 2006 12:04, Christian Ehrlicher wrote: >> Brad King schrieb: >>> Peter Kuemmel wrote: >>>> */Brad King <[EMAIL PROTECTED]>/* wrote: >>>> I've found that a KDE_DEPRECATED-style macro is insufficient across >>>> compilers. Some compilers want the decoration before the method and >>>> some want it after the method. In VTK I created a "VTK_LEGACY" macro >>>> that surrounds the method declaration. >>>> >>>> If we really need both positions then we could support this by >>>> using two macros: >>>> >>>> KDE_DEPRECATED_PRE void foo() KDE_DEPRECATED_POST >>>> >>>> or >>>> >>>> KDE_DEPRECATED_PRE >>>> void foo() >>>> KDE_DEPRECATED_POST >>>> >>>> So we could find a macro solution for all compiler. >>> ...as against just >>> >>> KDE_DEPRECATED(void foo()); >>> >>> with my suggestion. >> This could be an idea but in the last discussion I heard something like >> 'we support the same compiler like Qt and therefor we also could use the >> same deprecated-macro' ... >> >> In which places is KDE_DEPRECATED used? Only kdelibs? I won't break the >> complete kde4 source when I change kde_deprecated in any way... :) >> > > KDE_DEPRECATED is used in other modules (kdenetwork/kopete comes to mind) so > a > complete sweep of trunk/KDE will be needed, unless you just do kdelibs and > leave it to the app maintainers to fix their own apps. Then the idea to use KDE_DEPRECATED() is not easy to realise. The only way to to this would be to use a new macro name...
Christian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem