[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: QT_DEPRECATED_BEFORE/KF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x060000 considered harmful
From:       Roman Gilg <subdiff () gmail ! com>
Date:       2019-11-27 12:31:05
Message-ID: CAJcyoytnOtzz_B87u00ZXkDkt2BaeRh=BvZWKJht=uiGG38Keg () mail ! gmail ! com
[Download RAW message or body]

On Sat, Nov 2, 2019 at 11:04 PM Friedrich W. H. Kossebau
<kossebau@kde.org> wrote:
>
> Am Donnerstag, 24. Oktober 2019, 10:50:07 CET schrieb laurent Montel:
> > When a compilation is broken by a new deprecated method we will fix it.
>
> First though lots of people run into the build error, and are annoyed by it.
>
> As just happened know, because I properly added the missing deprecation markup
> for KDE_DEFAULT_WINDOWFLAGS, e.g. added visibility guards around it. As a
> result anyone building KDE software from git master still using this define,
> is now running into a build error when the project got
> KF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x060000 set.
>
> And I feel bad, because I triggered the build errors indirectly, due to the
> planned-breakage setup :/ While I just added proper deprecation tagging, as
> much as possible for a C++ preprocessor define.
>
> So doing good things -> breaking things for others unwanted. This harms the
> motivation to do good things. And also adds "break things" connotation to API
> deprecation work.
> So the mentioned setting even has counter-productive effects.
>
> So I would like to repeat my request to please reconsider this usage, even
> with the "is this a git checkout" check.,
>
> Cheers
> Friedrich

Thanks for bringing this issue up for discussion in the first place.
And nobody should see you at fault in any way. No reason to feel bad
about it.

I currently want to test KWin/Plasma on Qt 5.14 and several
side-projects did not compile because of the issue discussed here. It
was hard enough to get a Qt 5.14 build working on my system. And now I
have to dig through all kind of other projects' git logs, CMake files
and mailing list threads to find out why some projects like
KDecoration2 or systemsettings suddenly won't compile anymore.

And no, I won't update source code everywhere when I see builds fail
because of deprecated methods being used since this shouldn't lead to
a failed build in the first place and because I'm not inclined to run
behind unreviewed changes in all kind of different projects I'm not
involved in on a regular basis.

A grep on our source for this "EXISTS "${CMAKE_SOURCE_DIR}/.git" line
gave 118 results. So on new Qt versions am I supposed to first comment
out this code in all kind of different projects that I never work on
in order to get a functional desktop build again?

It is very annoying for one to track back the reason for such build
errors. Also reading this mailing list thread left me back with no
clear solution. These changes should have never gone in without prior
discussion and without making all KDE devs aware of what is being
tried here. And in my opinion they should be reverted ASAP. I did it
for systemsettings for now but I'm not the janitor for all the other
117 projects.
[prev in list] [next in list] [prev in thread] [next in thread]