CMake fails with CMake Error at adm/cmake/vtk.cmake:159 (endif): Flow control statements are not properly nested. Call Stack (most recent call first): CMakeLists.txt:14 (include) CMakeLists.txt:525 (OCCT_INCLUDE_CMAKE_FILE)
Could please post a build log and emerge info?
Created attachment 688155 [details] emerge --info output
Created attachment 688158 [details] build log
Thanks Helmut. Do you by chance use vtk-9?
(In reply to Bernd from comment #4) > Thanks Helmut. Do you by chance use vtk-9? No, I have 8.2.0-r1 installed here.
But there are more packages with this problem, like dev-db/mariadb and dev-db/mariadb-connector-c It might be connected to cmake-3.20.0_rc1 which is in use here.
(In reply to Helmut Jarausch from comment #6) > It might be connected to cmake-3.20.0_rc1 which is in use here. Most likely is. I wouldn't worry about these too much given, like for the previous widespread cmake EXPORT issues, it may get fixed in cmake itself. That version is also unkeyworded right now so it only affects the more adventurous.
(In reply to Ionen Wolkens from comment #7) > (In reply to Helmut Jarausch from comment #6) > > It might be connected to cmake-3.20.0_rc1 which is in use here. > Most likely is. > > I wouldn't worry about these too much given, like for the previous > widespread cmake EXPORT issues, it may get fixed in cmake itself. > > That version is also unkeyworded right now so it only affects the more > adventurous. Ok, thanks for the feedback. So I don't get into this right now. For me (using cmake 3.19.5) the build succeeded just 3 days ago, so I was wondering about this issue. Feel free to ping me again on this bug, if the error persists for later rc releases or the final release of 3.20.
Well, I may have spoke too soon, this may be the package's problem after all. asturm notably pointed out: >yup, that opencascade cmake file is broken >it's got one endif() too many before endforeach()
Ok, I'm gonna check it
asturm is correct. I wonder why this doesn't pop up with cmake-3.19...
(In reply to Bernd from comment #11) > asturm is correct. I wonder why this doesn't pop up with cmake-3.19... Much like with GCC upgrades, it's just more strict regarding things that shouldn't work. https://gitlab.kitware.com/cmake/cmake/-/commit/12f6e37eb79ad66c30269a3f19dfc28a9cb834e2 Still not impossible that this could be reverted before final, but hard to call this a cmake bug.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a05456f36a8e1c4c3c37695f3e9a621fccb4e801 commit a05456f36a8e1c4c3c37695f3e9a621fccb4e801 Author: Bernd Waibel <waebbl-gentoo@posteo.net> AuthorDate: 2021-02-24 21:07:32 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2021-03-01 08:25:54 +0000 sci-libs/opencascade: fix flow control dev-util/cmake >= 3.20.0_rc1 has restricted flow control checks. This patch fixes an issue with these new version on unbalanced flow control statements. Closes: https://bugs.gentoo.org/771300 Package-Manager: Portage-3.0.15, Repoman-3.0.2 Signed-off-by: Bernd Waibel <waebbl-gentoo@posteo.net> Signed-off-by: Joonas Niilola <juippis@gentoo.org> ...pencascade-7.4.0-fix-flow-control-nesting.patch | 31 ++++++++++++++++++++++ sci-libs/opencascade/opencascade-7.4.0-r4.ebuild | 1 + 2 files changed, 32 insertions(+)
