Corrected logic, so it is is in line with GNUInstallDirs. Explained in comment. Added tests.

@heikobecker are you still interested in this patch? I can take over otherwise.

(Just remember that using KDE_INSTALL_KNSRCDIR though needs at least KNewStuffCore from KF 5.57 (hint was missing in API dox, proposing D26248 to fix that).)

Not saying that this patch is wrong, would have to look into it more closely.

In D24568#580338, @kossebau wrote:

This has been missing the link from an rst file in docs/, so the documentation generation picks up the file. Fixed with c4890d5c03ed79f0c87da861b6608bbd46c2162c

This has been missing the link from an rst file in docs/, so the documentation generation picks up the file. Fixed with c4890d5c03ed79f0c87da861b6608bbd46c2162c

Use HINTS

LGTM overall

I tried to address the most recent comments:

The two links I know of are:
http://0pointer.de/lennart/projects/libcanberra (works as is in file but
wont work as https)
http://www.x86-64.org/documentation/abi.pdf (http://www.x86-64.org is dead)

In D25753#572894, @winterz wrote:

please send me a list of urls that don't have https: and I'll add them to the whitelist

please send me a list of urls that don't have https: and I'll add them to the whitelist

• Corrected URL as review comments

Corrected url to http://www.sphinx-doc.org

The sphinx doc URL is https://www.sphinx-doc.org (it just doesn't work without www)

• Corrections made per review comments.

Reverted some non-working URL's back to http and updated one URL to the correct address

In D25589#570375, @dfaure wrote:

My head hurts a bit but I think I understand this now ;)

My head hurts a bit but I think I understand this now ;)

In D25626#569714, @kossebau wrote:

Yay, thanks for fixing this. Not sure if if(MSVC) is the proper condition, due to not being into the windows side of things, so that part better has someone check who enters the dark side now and then. :)
Otherwise +1 for this.

I used it because it is the same condition inside ECMGenerateExportHeader.cmake which enables __declspec(deprecated(text)).

Yay, thanks for fixing this. Not sure if if(MSVC) is the proper condition, due to not being into the windows side of things, so that part better has someone check who enters the dark side now and then. :)
Otherwise +1 for this.

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)