In D24826#551280, @cullmann wrote:

As explained in the thread on https://phabricator.kde.org/T11214, this will make the formatting ugly as hell, as if you have long method names, stuff is broken in arbitrary bad ways.
I don't want to change that, if nobody can avoid the resulting breakage.

As explained in the thread on https://phabricator.kde.org/T11214, this will make the formatting ugly as hell, as if you have long method names, stuff is broken in arbitrary bad ways.
I don't want to change that, if nobody can avoid the resulting breakage.

Volker Ok'd it that I used that on the co-maintained KSyntaxHighlighting framework, too.

Ok, I pushed this now.

• keep default of BreakBeforeTernaryOperators = true

Has somebody tested the current state?

Without the initializer change, the file works for me reasonable well, tried it again on KTextEditor.

• avoid collapsing of constructor initializer lines

you get collapsed stuff like;

In D24568#548490, @dfaure wrote:

Do we want these, found in https://code.qt.io/cgit/qt/qt5.git/tree/_clang-format?

# We use template< without space.
SpaceAfterTemplateKeyword: false

# macros for which the opening brace stays attached.
ForEachMacros:   [ foreach, Q_FOREACH, BOOST_FOREACH, forever, Q_FOREVER, QBENCHMARK, QBENCHMARK_ONCE ]

# Break constructor initializers before the colon and after the commas.
BreakConstructorInitializers: BeforeColon

added that

• fix coding style issue, we don't want indented case labels
• add initial docs
• adjust style
• just tell the user it will not work

I like the idea very much.

Do we want these, found in https://code.qt.io/cgit/qt/qt5.git/tree/_clang-format?

I rewrote the patch to address the comments:

Do we have a request for this outside kbibtex? My attitude towards adding things to ECM is always "is there more than one user".

Perhaps David could give feedback if the file actually captures the intend to do proper KDE Frameworks/libs like formatting.
I had a mistake with the indented case statements, that should be fixed.

In D24568#545942, @cullmann wrote:

In D24568#545736, @apol wrote:

I'm not sure how this works, but would it be possible to have a target that only works on a patch? You usually want to make sure what you modified didn't diverge from the code.

I think there is some hack around that:
http://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting

But actually, if your sources are already clang-formatted, you just need to run the clang-format target once before you commit, the your new code will be the only thing altered.

In D24568#546289, @kossebau wrote:

There is also https://techbase.kde.org/Policies/Frameworks_Coding_Style which though missed the move from techbase to community, other than the other policies.

I suspect that page should be moved over now as well, to become the real KF coding style page (so that "kdelibs" named one is no longer needed).

@nalvarez @ochurlaud Do you remember why this page was not moved?

There is also https://techbase.kde.org/Policies/Frameworks_Coding_Style which though missed the move from techbase to community, other than the other policies.

I hope this file implements https://community.kde.org/Policies/Kdelibs_Coding_Style

If the KDE Frameworks developers have agreed to a common style, then yes, naming it KDE Frameworks style makes sense :)

In D24568#546227, @aacid wrote:

common KDE style file

There's no such thing as a common KDE style

common KDE style file

If there are more deviations from the kdelibs/frameworks coding style, please tell me.

• add initial docs

• fix coding style issue, we don't want indented case labels

In D24568#545736, @apol wrote:

I'm not sure how this works, but would it be possible to have a target that only works on a patch? You usually want to make sure what you modified didn't diverge from the code.

I'm all for it. This would unify how we can reformat any KDE module, which is very much desirable.

There is probably a way to run clang-format only on a patch. See http://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting

I'm not sure how this works, but would it be possible to have a target that only works on a patch? You usually want to make sure what you modified didn't diverge from the code.

To keep the momentum, now going to merge, given there was no objection when I pointed out the plan to move forward both here and in the email to frameworks-devel.
I assume no-one has time enough to wrap their brain around this as well and/or too many other competing stuff which has more of their interest.

switch to do generation-time decision about deprecated(text) attribute usage

improve documentation, especially about the generated C++ macros

Is this still relevant? If yes, from the diff, looks ok for me.

• update to David's findings in the docs

@apol Thanks again for your review work.

So, given the lack of further change proposals or objections, I would proceed to push this in the next days (Thurday evening or Friday morning), to have 3 weeks of pre-5.64 real world testing by CI and people running from git master.
See also https://mail.kde.org/pipermail/kde-frameworks-devel/2019-October/094708.html

• add missing group defaulting for warning settings, got lost in rebase before

In D23789#541134, @kossebau wrote:

In D23789#540033, @dfaure wrote:

I found confirmation in cmake's Tests/RunCMake/GenerateExportHeader/reference/

Not sure what you exactly mean, can you please specify confirmation for what? And what this recommends us to do? :)

• extend unit tests to cover library group macro variants

Sadly blows up by all combinations unit test time to >1 min on old machine

In D23789#540033, @dfaure wrote:

I found confirmation in cmake's Tests/RunCMake/GenerateExportHeader/reference/

• extend *_VERSION_DEPRECATED to expect third argument "text" first experimental consumption time support for "text" output with GCC compiler
• make *_NO_DEPRECATED a proper shortcut for DISABLE_BEFORE_AND_AT=CURRENT
• extend unit test to cover *_NO_DEPRECATED

+1

I found confirmation in cmake's Tests/RunCMake/GenerateExportHeader/reference/

In D23789#539940, @dfaure wrote:

I see the theoretical problem, but how could this ever be a problem in practice?
On Unix all compilers support the same syntax (__attribute__ ((__deprecated__))), so you'd have to be on Windows, build a library with mingw, and then try to use it with MSVC, or vice-versa? I wonder if this even works. AFAIK it doesn't (hence the compiler-specific binary installers for Qt, for instance).

Which might be an issue for people who would like to use different compiler on the same system, both building against the same generated export header file.

Quick Update (week 40):
Locally have added experimental code to even set the proper attribute for GCC compiler, so we get e.g.:

In D23789#538985, @kossebau wrote:

• why has all Qt code not yet been adapted to QT_DEPRECATED_VERSION/QT_DEPRECATED_VERSION_X, are there places where those macros should not be used, but the version-less ones?

Because noone wanted to do the work and it was added late in the Qt5 lifetime -> A lot of stuff was deprecated for a long time already (in Qt4 times) and there is was a replacement since Qt5.0.0 so the macro was not needed (even though a lot of people got very angry about it). I added it for some new signals which created a lot of discussion since the old ones are widely used.

Can you point to those discussions? Would be curious to learn what people's thought are.

https://lists.qt-project.org/pipermail/development/2019-March/035343.html

Thanks for your reply, Christian :)

In D23789#536338, @kossebau wrote:

Actual questions I have:

• why is QT_DEPRECATED_WARNINGS_SINCE not officially documented? like, any plans to change that macro to something else?

Just forgot it (and also the reviewers) I would guess. There is no plan to change it, at least none I'm aware of. I'm looking for an automatic generation of this macro. Since Qt6 switches to CMake I can maybe borrow some stuff from you ;)

Thanks, landed in 3b0bf71a72789eb2b79310b4f67602115e347f56

Looks safe to me, should not change the non-EMSCRIPTEN behavior.

add first set of unit tests covering the main functionality.
Feedback on principal approach wanted!

In D24159#536388, @kossebau wrote:

Should the new module be part of public ECM macros? Then it misses a documentation linking file docs/module/ECMSourceVersionControl.rst

Should the new module be part of public ECM macros? Then it misses a documentation linking file docs/module/ECMSourceVersionControl.rst

@chehrlic Hi. As I just discovered, you are the author of the macros for Qt (commit) which I took as inspiration/blue print when designing this here. So, curious what you think of your work now and if you can already point out things where you see potential for improvements. And also curious what you think of this approach here :)

Quick Update (week 39):
took me a bit longer to design and write tests, not trained to write such things in cmake code, all its magic & caches & scopes + own undiscovered typos make this not (yet?) fun, and I am not certain I have done things properly, so will be looking forward to feedback.
Currently cleaning up and documenting the code, added tests should land tonight with an update here (and they already found an error in the so far prototype code :) ).

Quick update:
Currently still busy trying to get unit tests done, half-way through that. ETA begin of upcoming week.
Next plan: see how only having the 3-arg-FOO_DEPRECATED_VERSION(major. minor, message) would work by using that in the experimental patches done for some KF repos.

I don't know doxygen very well, but the cmake change seems sensible.

Can we move forward on this?

I wouldn't offer both variants, but rather recommend always adding a hint. At worse that hint can be "See method documentation" or an empty string. I think we're just over-complicating things otherwise, for no actual gain, since providing a hint is good practice anyway.

• reword documentation based on dfaure's comments
• bump since-version to 5.64.0, as currently targetted introduction version

@dfaure Thanks for first in-detail feedback, good to get a feeling this is not totally insane over-engineered stuff to other people'e eyes :)

Great work. Not really easy to grasp at first sight (because it handles BC for no-compat builds of the lib itself, which we never did before) but this is certainly quite comprehensive.

Would push upcoming WE if there are no objections.
And then also adapt all KF modules to make use of this new argument, for better results and less need for predefined macros.