In D24990#564667, @kossebau wrote:

Hm, only noticed now that this actually has an unwanted sideeffects: it triggers deprecation warnings for all deprecated warning also inside each library itself. Which is not what one wants.

Fabian fixes

Wow, this part of systemd is surprising :/

AFAICT this breaks if LIBDIR != "lib". systemd only looks in /usr/lib AFAICT, so hardcoding to $prefix/lib/systemd might be better.

In D24990#564670, @dfaure wrote:

So we need to set FOO_DISABLE_DEPRECATED_BEFORE_AND_AT to N-1 while building FOO itself, right? Either magically here, or manually in every module...

So we need to set FOO_DISABLE_DEPRECATED_BEFORE_AND_AT to N-1 while building FOO itself, right? Either magically here, or manually in every module...

Hm, only noticed now that this actually has an unwanted sideeffects: it triggers deprecation warnings for all deprecated warning also inside each library itself. Which is not what one wants.

Btw., I just tried e.g.

For the lambda issue, I think we can add:

Let's just reopen this and work on improving it.

In D24568#563092, @davidedmundson wrote:

As an update on this from the Plasma POV.

I added the macro to every repo and told every dev to do a final test before we commit the formatted results.

I had some feedback and the result was that we can't proceed with in the current state [1].

What's noteworthy is we were generally ok with the results from the first file we prepared in T11214, so potentially we just need some settings tweaked.
I'll try and break that down into future diffs.

1.https://mail.kde.org/pipermail/plasma-devel/2019-November/106186.html

You can force the current clang format to keep the multi-line if as follows:

As an update on this from the Plasma POV.

This is starting to look really good. All functions will need documenting in the header of that file so they show up on api.kde.org, see other modules for examples.

I applied the patch to our openexr package instead.

The pkgconfig file disagrees:
it contains libsuffix=-2_4 and later Libs: -L${libdir} -lIlmImf${libsuffix}
For me, that library name is correct

In D25304#562561, @arojas wrote:

I don't see how that commit is related.
openEXR 2.3 installs libXXX.so and 2.4 installs libXXX-2_4.so

This is expected afaics.

No, it's not. That line in openexr is supposed to link libXXX-2_4.so (${verlibname}) to libXXX.so (${baselibname}) but it does so in the wrong dir

I don't see how that commit is related.
openEXR 2.3 installs libXXX.so and 2.4 installs libXXX-2_4.so

This is expected afaics.

In D25304#562553, @arojas wrote:

This is a bug in openexr. It does actually try to install the unsuffixed symlinks, but it doesn't take DESTDIR into account, so it tries to install them to the root filesystem instead of doing so inside DESTDIR as it should. It is fixed in https://github.com/openexr/openexr/commit/4e54bde78f65c0fef8a9f794aaacea07813fba09

This is a bug in openexr. It does actually try to install the unsuffixed symlinks, but it doesn't take DESTDIR into account, so it tries to install them to the root filesystem instead of doing so inside DESTDIR as it should. It is fixed in https://github.com/openexr/openexr/commit/4e54bde78f65c0fef8a9f794aaacea07813fba09

Note: openEXR >= 2.4 provides CMake configuration modules (OpenEXRConfig.cmake and IlmBaseConfig.cmake). We could also look for those and use the current code as a fallback if the modules can't be found

FYI: Today I added a Krazy checker to do this. Should see results on the EBN in a day or 2.

Merci, will land later tonight. Bonnes vacances :)

Done (in the process of being pushed), you can push this.

@dfaure Hi. Any chance you you can sneak in before you are away (enjoy :) ) to remove the "-DQT_DEPRECATED_WARNINGS_SINCE=0x060000" from all the KF modules in the next days? Otherwise would land this here with just the -DKF_DEPRECATED_WARNINGS_SINCE=0x060000 for now, otherwise people do not see warnings in KF modules when they should.

I updated the diff. I was quite surprised about the time it takes to compute the number of commits (26 seconds), thus I removed this functionality completely. As of now, only 'revision' and 'branch' are queried for.
There are three functions now:

Hm, how about separate functions though? With a single stat any given build still needs N process forks even when they only want 1 value.

In D24841#552842, @vonreth wrote:

Where are those tests running? I'm only aware of https://build.kde.org/job/Frameworks/job/extra-cmake-modules/

In D24841#552600, @cgiboudeaux wrote:

Another issue caused by the new CMake 3.5 dependency, some tests fail:

59 - ecm_setup_version-old_simple (Failed)
60 - ecm_setup_version-old_soversion (Failed)
61 - ecm_setup_version-old_version_file (Failed)
62 - ecm_setup_version-old_version_file_abspath (Failed)
63 - ecm_setup_version-old_version_file_anynewer (Failed)
64 - ecm_setup_version-old_version_file_exact (Failed)
65 - ecm_setup_version-old_version_file_samemajor (Failed)
66 - ecm_setup_version-old_header (Failed)
67 - ecm_setup_version-old_header_abspath (Failed)

(+2 others not related to the recent changes)
I didn't look yet at the details. My guess is the CMake policy changes between 2.8.12 and 3.5

Another issue caused by the new CMake 3.5 dependency, some tests fail:

Thanks! tested successfully

Does https://phabricator.kde.org/D24882 help? (Not tested)

In D24841#552577, @dfaure wrote:

Where did -std=gnu++14 come from? The old code above certainly didn't set it.

Maybe some projects were doing set(CMAKE_CXX_STANDARD 14) before including KDECompilerSettings? We could test the var here to avoid overwriting it...

Where did -std=gnu++14 come from? The old code above certainly didn't set it.

I'm seeing build failures in several repositories seemingly caused by 6e3c794 (eg akonadi, kasync)

• Raise CMake requirements to 3.5

Dunno, it's harder to justify in a standalone review :)
"Increase dependency, just because" ;)

I guess we should do that in a separate review?

Fix

Works for me.

If you want to increase cmake dependency, we should at least increase it to 3.5

CMAKE_CXX_STANDARD_REQUIRED

In D24841#551653, @chehrlic wrote:

I would also use CMAKE_CXX_STANDARD_REQUIRED to make sure the compiler actually *can* c++11, otherwise the flag is only added when the compiler supports it. Should not make much difference nowadays but since it's in ECM...

I would also use CMAKE_CXX_STANDARD_REQUIRED to make sure the compiler actually *can* c++11, otherwise the flag is only added when the compiler supports it. Should not make much difference nowadays but since it's in ECM...

Change message

See the other task: columnlimit 0 leads to endless long lines and is a unusable default.

I am a long-time advocate of columnLimits; however, in our modern world of programming I think 100 is too short.

I suggest to set ColumnLimit to 0 by default and allow projects to override it.

Perhaps easiest way to see what happens: apply it to one of your things and vary the value.

It is unfortunately very brutal and in-deed, it can create very long lines if you have matching bad constructs.

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.