- pkgconfig is now quiet
- variables are now camelcase
- old variables are still set for compat
- new imported target (also sets pkgconfig's cflags, which I presume is the sane thing to do)
- set package description url & description
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Feb 18 2019
If someone could please trigger all of the Dependency Builds for FreeBSD once this has been landed that would be appreciated: https://build.kde.org/view/Failing/
In D19005#412258, @vkrause wrote:Actually having tested this, "deprecated_value" looks wrong there, shouldn't this be "default_value"?
Feb 17 2019
Feb 16 2019
Search for pkgconfig quietly.
In D18952#413454, @aacid wrote:Yes, imported targets are the future/present :)
Canberra::Canberra sounds good to me as target name
Simply set NAMES EGL/egl.h and fixup the header version check.
In D19075#413462, @hausmann wrote:I think that it should be NAMES EGL/egl.h
I think that it should be NAMES EGL/egl.h
Yes, imported targets are the future/present :)
Store the path gathered via pkgconfig in COMPLETE_EGL_INCLUDE_DIR and
use its parent directory for EGL_INCLUDE_DIR.
Yeah I think find_path should use the same style as the test program (EGL/egl.h). It is the style of inclusion as per the specification. I think that’s better than the ../ approach.
Possibly the returend EGL_INCLUDE_DIR should possibly be stripped of the suffix too, as most will proably include 'EGL/egl.h', and not 'egl.h', I guess?
/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
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?