/usr/local/bin/gmake -f CMakeFiles/cmTC_fd24d.dir/build.make CMakeFiles/cmTC_fd24d.dir/build gmake[1]: Entering directory '/usr/home/jenkins/kwayland/build/CMakeFiles/CMakeTmp' Building CXX object CMakeFiles/cmTC_fd24d.dir/src.cxx.o /usr/bin/c++ -I/usr/local/include/EGL -DHAVE_EGL -o CMakeFiles/cmTC_fd24d.dir/src.cxx.o -c /usr/home/jenkins/kwayland/build/CMakeFiles/CMakeTmp/src.cxx /usr/home/jenkins/kwayland/build/CMakeFiles/CMakeTmp/src.cxx:2:10: fatal error: 'EGL/egl.h' file not found #include <EGL/egl.h> ^~~~~~~~~~~ 1 error generated. gmake[1]: *** [CMakeFiles/cmTC_fd24d.dir/build.make:66: CMakeFiles/cmTC_fd24d.dir/src.cxx.o] Error 1 gmake[1]: Leaving directory '/usr/home/jenkins/kwayland/build/CMakeFiles/CMakeTmp' gmake: *** [Makefile:121: cmTC_fd24d/fast] Error 2
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Feb 16 2019
Feb 15 2019
Thanks!
Feb 14 2019
In fact none of those seem to work here. D19016 works here though, and I suspect that the 14 -> 21 in there should fix ECM on the CI.
Actually having tested this, "deprecated_value" looks wrong there, shouldn't this be "default_value"?
Ooops. Could you paste the error from the cmake error output? I'm curious which part of the EGL compile test fails.
Feb 13 2019
In D18960#411562, @kossebau wrote:Seems this is sadly breaking something for FreeBSD though, see
https://build.kde.org/job/Frameworks/job/kwayland/job/kf5-qt5%20FreeBSDQt5.12/21/console
Seems this is sadly breaking something for FreeBSD though, see
https://build.kde.org/job/Frameworks/job/kwayland/job/kf5-qt5%20FreeBSDQt5.12/21/console
Good point, I've also noticed that (all?) our finders now also create an IMPORTED target. Should we maybe add that too? If so I guess Canberra::Canberra would be the preferred target name?
document in rst syntax
Feb 12 2019
Update indentation, add docs link, remove ancient copy from attic.
+1 This makes sense to me, considering how broken some vendor [E]GL stacks are.
Could the indentation perhaps be turned to be 4 spaces while copying it here? While https://community.kde.org/Policies/CMake_Coding_Style#Indentation allows the choice of 2,3, or 4 spaces, using 4 is more in line with the indentation used in C++ sources, so IMHO more expected to read.
I just realized there is a much older version of this in attic/modules already, should that be removed as part of adding this?
In D18943#410391, @cgiboudeaux wrote:I'm not sure to understand the commit message, does qtbase look for ECM ?
Add since tag.
I'm not sure to understand the commit message, does qtbase look for ECM ?
Feb 11 2019
Feb 10 2019
Feb 5 2019
Feb 4 2019
LGTM, thanks!
Feb 3 2019
Now tested more exhaustively and with unittest.
Addressed comments
Feb 2 2019
You also need to change '-Xclang -add-plugin -Xclang clang-lazy' to '-Xclang -add-plugin -Xclang clazy' for the plugin to actually be used.
Note: this will break with older clazy versions. I'm not sure how to prevent that.
One could argue that a developer interested in clazy should probably run the latest version anyway...
Jan 31 2019
So according to you, this line is useful ? from my point of view, it's needless and just looks like a syntax error.
In D16894#402901, @rjvbb wrote:Forget that. The syntax is confusing, please remove this HASFLAG
That I'm not going to do. The goal is to both to have useful feedback like below, and to avoid caching issues that would cause on the first query to be performed (if you were to use a single result variable):
-- Performing Test Clang++_ACCEPTS-Wvla ``
Forget that. The syntax is confusing, please remove this HASFLAG
In D16894#402701, @rjvbb wrote:There are tests for other ECM modules in the **tests** subdir.That's not the expected answer, so let me rephrase: which existing test can I clone and adapt (which is about the only thing I know how to do in this domain)?
There are tests for other ECM modules in the **tests** subdir.
In D16894#402364, @rjvbb wrote:
Updated as requested.
Jan 30 2019
Right, but I was saying all this because I think IF_SUPPORTED (the keyword in the arguments) should be SUPPORTED_IF.
In D16894#402209, @rjvbb wrote:In that sentence, one can read "if supported" for the macro name, ...That was my idea too, and the reason the macro ends in "_if_supported".
PS: don't forget the unit test for the new module.
In that sentence, one can read "if supported" for the macro name, ...
Jan 29 2019
SUPPORTED_IF : add the flag(s) if the expression is true?
Yes.
Jan 28 2019
This follows David's suggestion, but using QUERY_IF instead of the suggested TRY_IF to make it clear that this parameter controls the querying of the compiler.
I haven't yet tested the new logic exhaustively but the as far as I can tell the macro behaves as intended as used in the two compiler settings modules.
Usually if you have a conditional behaviour the associated condition specifies when to trigger it, no?
You're right that the names don't suggest exactly how the condition is being evaluated (with extra checks or not), but that was also a bit the idea.
Don't bother the user with such details, just provide a macro that will add the flag(s) if they are supported, with an optional conditional expression that can make things faster.
Ah. You meant an "OR", I thought it was an "AND". (as in our known selection of compilers OR/AND appleclang supports it)
But things are certainly not clearer now with the name CONDITION, which doesn't imply either one.
Jan 27 2019
Renamed macro and parameter names as announced in my last comment.
In D16894#400949, @dfaure wrote:This makes sense to me. Just the name "SUPPORTED_IF" is strange, when reading that, one thinks "well, if we know the compiler flag is supported, why are we testing that it is?".
like René says, this is quite surprising
Hmmm, did I say exactly that? :)
This makes sense to me. Just the name "SUPPORTED_IF" is strange, when reading that, one thinks "well, if we know the compiler flag is supported, why are we testing that it is?". I think this should be something like TRY_IF.
Then it's clearer that no harm will occur if we set a too low compiler version after TRY_IF, it's just an optimization to avoid e.g. testing all gcc flags on MSVC and vice-versa.
If it fixes the issue, this can go in, but like René says, this is quite surprising, since the default behavior (CMP0025 off) is that the compiler is called "Clang" on Apple platforms as well.
See cmake --help-policy CMP0025
Jan 26 2019
This is in fact cmake's fault, or ECM's for not taking a cmake quirk into account.
Oh, Hannah updated the summary, so an unknown option makes visibility stuff fail?
You sure about that? AFAICS from https://binary-factory.kde.org/view/MacOS/job/Kate_Release_macos/346/console it's just a warning, otherwise, ninja would stop after the first error, and it continues until a linking failure happens
This change is somewhat urgent - as can be seen at https://binary-factory.kde.org/view/MacOS/ all Mac builds are currently broken due to this issue.
See also https://phabricator.kde.org/D16894 which (initially) aimed to tackle this in a more general fashion.
In D18547#400298, @aacid wrote:Why?
Why?
Jan 25 2019
Jan 23 2019
In D18167#398360, @aacid wrote:In D18167#398343, @kossebau wrote:only 3(?) days between proposal and commit was also a very rushy
Check your dates better please, it's 9 days
In D18167#398076, @graesslin wrote:The human error exists as long as clang-tidy is not used. What I fear is that someone does a hand porting - we have seen several attempts to do that in KWin from various developers. If devs don't know and now fix the warnings, they can bring in human error.
In D18167#398343, @kossebau wrote:only 3(?) days between proposal and commit was also a very rushy
In D18167#398076, @graesslin wrote:The human error exists as long as clang-tidy is not used. What I fear is that someone does a hand porting - we have seen several attempts to do that in KWin from various developers. If devs don't know and now fix the warnings, they can bring in human error.
Jan 22 2019
In D18167#398076, @graesslin wrote:The human error exists as long as clang-tidy is not used. What I fear is that someone does a hand porting - we have seen several attempts to do that in KWin from various developers. If devs don't know and now fix the warnings, they can bring in human error.
Almost every project has already been gone over with clang-tidy.
Including kwin which was then force-pushed back by you. This was back in June 2017.
I've got little sympathy if we have a warning after explicitly reverting the fix to the warning.
The human error exists as long as clang-tidy is not used. What I fear is that someone does a hand porting - we have seen several attempts to do that in KWin from various developers. If devs don't know and now fix the warnings, they can bring in human error.
Jan 21 2019
qhelpgenerator is back in Qt 5.12.1
In D18167#397319, @graesslin wrote:For done code this warning is pointless and negative. I invite you to work with a code base like KWin where it is more important to have a working git blame than protection for theoretical problems. Nobody will be able to guarantee that a 500+ change to add override won't break. Human errors happen, nobody will be able to review something like that. Addressing this warning by adding override all over our legacy code base has a serious risk.
I'm seriously pissed that this is forced on us and we have to change code.
I'm totally fine with this warning for new code and new projects. But let projects opt in for it instead of forcing it on legacy code bases.
For done code this warning is pointless and negative. I invite you to work with a code base like KWin where it is more important to have a working git blame than protection for theoretical problems. Nobody will be able to guarantee that a 500+ change to add override won't break. Human errors happen, nobody will be able to review something like that. Addressing this warning by adding override all over our legacy code base has a serious risk.
Jan 20 2019
In D18167#397020, @graesslin wrote:This causes in KWin 500+ new warnings. Do you really think it's a good idea to spam all of KDE with new compiler warnings. KDE has an old code base. We cannot enable warnings for the way you developed C++ for 20 years.
This causes in KWin 500+ new warnings. Do you really think it's a good idea to spam all of KDE with new compiler warnings. KDE has an old code base. We cannot enable warnings for the way you developed C++ for 20 years.
Jan 19 2019
Jan 18 2019
As far as I understand the logic of the whole thing, it looks sane. At some point we ought to find a way to properly test that the generated code...