Review Request 115028: Allow the building of deprecated code to be disabled

[Alex Merry]

> On Jan. 27, 2014, 2:14 a.m., Aleix Pol Gonzalez wrote:
> > Shouldn't we maybe just remove these? Especially considerign they already are deprecated in kdelibs 4.
> > 
> > I don't really like disabling compilation of deprecated symbols, especially in this case we're not winning that much.
> 
> Kevin Ottens wrote:
>     The better approach would be to make it inline so that it's not in the cpp file at all:
>     
>     #ifndef KDE_NO_DEPRECATED
>         QString fullName() const { return property(KUser::FullName); }
>     #endif
>

If we don't want the option of disabling compilation, why are we using the #ifndef construction at all?

What about the other parts of this, like replacing KDE_NO_DEPRECATED with KCOREADDONS_NO_DEPRECATED and supressing deprecation warnings while building with the KCOREADDONS_DEPRECATED= definition?


- Alex


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115028/#review48324
-----------------------------------------------------------


On Jan. 15, 2014, 1:56 p.m., Alex Merry wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115028/
> -----------------------------------------------------------
> 
> (Updated Jan. 15, 2014, 1:56 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> -------
> 
> This is mostly an example of how we could improve the deprecation handling.  There are two parts: preventing deprecation warnings when building the library itself (see http://build.kde.org/view/Frameworks/job/kwidgetsaddons_master_qt5/11/warnings17Result/NORMAL/package.-1402078525/ for examples) and allowing the framework to be built with no deprecated code.
> 
> We possibly want to export the fact that the framework was built without deprecated code via the CMake config file, so that downstream stuff (like kde4support) can check for it and complain if necessary.
> 
> 
> Allow the building of deprecated code to be disabled
> 
> This adds a CMake option to enable or disable the building of deprected
> code.  It just changes the kcoreaddons_export.h file.
> 
> Part of this change is to use KCOREADDONS_NO_DEPRECATED instead of
> KDE_NO_DEPRECATED.
> 
> Disable deprecation macro when building the library itself
> 
> This prevents spurious compiler warnings (particularly when slots are
> deprecated).
> 
> 
> Diffs
> -----
> 
>   src/lib/CMakeLists.txt 8cc71f34e671962f2d7268b3db0d50e6750c26a2 
>   src/lib/util/kuser.h 2b6e6ed92bc1465945f36f2fde821f36fa51585f 
>   src/lib/util/kuser_unix.cpp 8a3a39d379ca863b4906bb01228c5e01a5b955b0 
>   src/lib/util/kuser_win.cpp 6a6cbb1751bd569d8684f8e11add1ef304c0a94d 
> 
> Diff: https://git.reviewboard.kde.org/r/115028/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Alex Merry
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140128/fded4863/attachment.html>