I tried to address the most recent comments:
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Dec 9 2019
Dec 8 2019
Dec 6 2019
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
Dec 5 2019
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
Dec 4 2019
Dec 1 2019
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 ;)
Nov 30 2019
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.
Nov 28 2019
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.
Nov 26 2019
Nov 25 2019
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.
Nov 24 2019
Nov 19 2019
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.
Nov 17 2019
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
Nov 16 2019
You can force the current clang format to keep the multi-line if as follows:
Nov 15 2019
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.
Nov 14 2019
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.soThis 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.soThis 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
Nov 8 2019
FYI: Today I added a Krazy checker to do this. Should see results on the EBN in a day or 2.
Nov 3 2019
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:
Nov 1 2019
Oct 28 2019
Oct 27 2019
Oct 24 2019
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.
Oct 23 2019
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)
Oct 22 2019
Oct 21 2019
- 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.