cmake.eclass appends this to CMakeLists.txt: MESSAGE(STATUS "<<< Gentoo configuration >>> Build type \${CMAKE_BUILD_TYPE} Install path \${CMAKE_INSTALL_PREFIX} Compiler flags: Suggestion to use lowercase message: It is not compatible with ancient cmake but shouldn't be a problem for us. Uppercase macro causes some linter tests to fail for some of my packages. Recent cmake documentation always uses lowercase functions/macros. Reproducible: Always
*** Bug 738494 has been marked as a duplicate of this bug. ***
*** Bug 736948 has been marked as a duplicate of this bug. ***
*** Bug 736944 has been marked as a duplicate of this bug. ***
*** Bug 736942 has been marked as a duplicate of this bug. ***
see dupes for examples of test failures
*** Bug 734084 has been marked as a duplicate of this bug. ***
*** Bug 734096 has been marked as a duplicate of this bug. ***
What are these ROS packages doing that they fail tests just because of uppercase cmake functions?
(In reply to Andreas Sturmlechner from comment #8) > What are these ROS packages doing that they fail tests just because of > uppercase cmake functions? as written in comment #0 : they use a linter on the cmakelists.txt; theirs is fine, the linter reports an error with what cmake.eclass adds
I've seen that; but why? I mean, they can do that upstream, fine, but doing this has zero benefit on packaging level, right? While there isn't really anything speaking against changing cmake.eclass to lowercase macro calls, it is not really a fix for the problem in principle. What if their linter comes up with whitespace errors next time around? Or what do we tell maintainer of package X that is now going fail because we add lowercase macro calls in cmake.eclass?
(In reply to Andreas Sturmlechner from comment #10) > I've seen that; but why? I mean, they can do that upstream, fine, but doing > this has zero benefit on packaging level, right? > > While there isn't really anything speaking against changing cmake.eclass to > lowercase macro calls, it is not really a fix for the problem in principle. > What if their linter comes up with whitespace errors next time around? Or > what do we tell maintainer of package X that is now going fail because we > add lowercase macro calls in cmake.eclass? yes, it does not make that much sense; my thought was more that it fixes my problem and lowercase macros seem to be the norm these days (couldn't find any real reference, only ml posts saying it is better to use lowercase now) an option in cmake.eclass telling it not to touch cmakelists works for me too btw
Your problem is fixed by disabling the upstream linter or hiding that behind a cmake option. I will probably change the eclass anyway.
(In reply to Andreas Sturmlechner from comment #12) > Your problem is fixed by disabling the upstream linter ...and it could look like that: > src_test() { > # bug 739230 > local myctestargs=( > -E "(lint_cmake)" > ) > > cmake_src_test > }
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/kde.git/commit/?id=782ded1ef76176ce39f37e3419daaeb5e2872b88 commit 782ded1ef76176ce39f37e3419daaeb5e2872b88 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2020-08-30 21:15:39 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2020-09-04 12:14:13 +0000 cmake.eclass: Reformat the cmake code we write to lowercase calls Add some indendation, drop space between function name and brackets, cleanup old style if-else-endif. Bug: https://bugs.gentoo.org/739230 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> eclass/cmake.eclass | 106 +++++++++++++++++++++++++--------------------------- 1 file changed, 51 insertions(+), 55 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a26f145f893c3aeffbbbd6ff7dac932c44b6e024 commit a26f145f893c3aeffbbbd6ff7dac932c44b6e024 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2020-08-30 21:15:39 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2020-09-29 13:55:37 +0000 cmake.eclass: Reformat the cmake code we write to lowercase calls Add some indendation, drop space between function name and brackets, cleanup old style if-else-endif. Bug: https://bugs.gentoo.org/739230 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> eclass/cmake.eclass | 106 +++++++++++++++++++++++++--------------------------- 1 file changed, 51 insertions(+), 55 deletions(-)
(In reply to Larry the Git Cow from comment #15) > The bug has been referenced in the following commit(s): > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=a26f145f893c3aeffbbbd6ff7dac932c44b6e024 > > commit a26f145f893c3aeffbbbd6ff7dac932c44b6e024 > Author: Andreas Sturmlechner <asturm@gentoo.org> > AuthorDate: 2020-08-30 21:15:39 +0000 > Commit: Andreas Sturmlechner <asturm@gentoo.org> > CommitDate: 2020-09-29 13:55:37 +0000 > > cmake.eclass: Reformat the cmake code we write to lowercase calls > > Add some indendation, drop space between function name and brackets, > cleanup old style if-else-endif. > > Bug: https://bugs.gentoo.org/739230 > Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> > > eclass/cmake.eclass | 106 > +++++++++++++++++++++++++--------------------------- > 1 file changed, 51 insertions(+), 55 deletions(-) that is good enough for me now
Don't file a bug against cmake.eclass the next time you hit a bug about this then.
(In reply to Andreas Sturmlechner from comment #17) > Don't file a bug against cmake.eclass the next time you hit a bug about this > then. Unless there's something 'weird' done by the eclass or easily fixed, I won't, obviously. I'm not very keen on maintaining non upstreamable patches, or a list of tests to exclude, because our way of building cmake packages magically modifies upstream sources though.
