Created attachment 127037 [details] build.log This is a regression over 4.2.8. cmake-3.17.0 ilmbase/openexr-2.3.0 ... CMake Error at cmake/modules/FindOpenEXR.cmake:43 (string): string sub-command REGEX, mode MATCHALL needs at least 5 arguments total to command. Call Stack (most recent call first): CMakeLists.txt:569 (find_package) CMake Error at cmake/modules/FindOpenEXR.cmake:49 (string): string sub-command REGEX, mode MATCHALL needs at least 5 arguments total to command. Call Stack (most recent call first): CMakeLists.txt:569 (find_package) CMake Error at cmake/modules/FindOpenEXR.cmake:55 (string): string sub-command REGEX, mode MATCHALL needs at least 5 arguments total to command. Call Stack (most recent call first): CMakeLists.txt:569 (find_package) -- Found OpenEXR: /usr/include;/usr/include/OpenEXR
We build Krita with v2.4.0 on four platforms, and I build locally with v2.2.0, and I don't get these errors...
I suspect it's not openexr, but the version of cmake you're using. I'm using 3.10.2 locally.
That is possible, and I will give it a try in the evening, however 4.2.8.2 was fine with that version of cmake.
Same result with cmake-3.16.5, 3.14.6 and 3.13.5 which is the oldest version I can test with. Happy to provide any additional information, I haven't had time myself to look into the particular failing lines yet.
I have this same issue. But thing is I had a successful build prior to trying to update krita a few days ago. All using the same cmake version in gentoo cmake-3.16.5. I also downgraded the cmake version and have the same error. The only thing that is different is that I have upgraded to kde-frameworks/extra-cmake-modules-5.68.0 since the last time that I built krita. But I do not know if that would affect the build.
Created attachment 127190 [details] krita-4.2.9-ecm-findopenexr.patch fixed using the attached patches
After my current rebuild, I'll reboot to windows and see what happens there.
And that was a month ago... But I'm on Windows now, and if I apply that patch, openexr isn't found at all: -- The following OPTIONAL packages have not been found: * OpenEXR, High dynamic-range (HDR) image file format, <https://www.openexr.com> Required by the Krita OpenEXR filter
Stranger still, if I update to cmake 3.17.2, I still don't get these errors.
@Boudewijn Rempt I have been still trying to build krita but I keep getting the error but I noticed that right after the error it checks openexr and marks it as found. Is the order of the build causing the errors?
just to add more info to this thread Compiled krita on tumbleweed no problems cmake: 3.17.2 openexr: 2.4.1-1-.1 Please try with openexr 2.4.1. Gentoo can be overly enthusiat and include not so stable packages in "stable". Sometimes is needed to add a package.keyword to get the patched version. If not make sure you are not using any strange gentoo overlay. also check if in the ebuild steps there is no suspicious gentoo patch.
@vanyossi Thank you very much for these pointers!! It was just what I needed to get it working. I was able to find that not only was the version of openexr an older version but also that my binutils was masked and using an outdated version. I had to use an overlay to get the openexr: 2.4.1-1-.1 version. I had already had cmake: 3.17.2 installed. Now my cmake command is building and I am running make right now, and so far it is working a treat. Thank you very much for pointing me in the right direction.
I disagree. $ equery l openexr * Searching for openexr ... [IP-] [ ] media-libs/openexr-2.3.0 ^ that's not from an overlay, that's certainly not 'overly enthusiast' a version. If krita's build system does not correctly detect that version, then maybe it should raise the minimum version, although it would be pity for something that 'just works' with the ECM version of openexr module detection.
And, arguably, if the ECM cmake module for OpenEXR has a bug for detecting OpenEXR on Windows, that would be nice to get fixed in ECM itself for the benefit of all ECM based projects.
The media-libs/openexr-2.3.0 was the only version that portage has, that is why I had to use an overlay for the newer version. I am not sure if that was the same version that had been working before.
That's why we don't close bugs based on speculation or the Gentoo overly enthusiast trope.
Note: Krita has never used ecm's FindOpenExr.cmake find module. The current one, from Pixar, replaces an older one that couldn't find openexr on Windows.
Ah, I was misled by commit d978a33a then.
So I had the chance to try with openexr-2.5.2 and krita git master detects it fine unmodified. Which means the regex thing is just too brittle to reliably detect 2.3.0 for some reason, and I would not be too confident for this issue not to come up again in the future.
Wasn't this fixed by now?
(In reply to Halla Rempt from comment #20) > Wasn't this fixed by now? That depends how you look at it. cmake/modules/FindOpenEXR.cmake didn't receive any fix for that meanwhile. I'm still applying the patch to use ECM FindOpenEXR to krita 4.4.2 because I know it works and our repository still provides the older openexr-2.3.0 (even if likely not used by krita users) besides >=2.5 where Pixar's module seems to work. - Can we be sure it won't break in the future? - Shouldn't ideally be ECM's module be fixed to work with Windows?
Yes, ideally we'd fix it in ECM, but I haven't got any idea how to properly fix this.
If the ECM module works everywhere *except for Windows*, I know what the issue is. Assigning.
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/1049
(In reply to Andreas Sturmlechner from comment #21) > (In reply to Halla Rempt from comment #20) > > Wasn't this fixed by now? > That depends how you look at it. cmake/modules/FindOpenEXR.cmake didn't > receive any fix for that meanwhile. > > I'm still applying the patch to use ECM FindOpenEXR to krita 4.4.2 because I > know it works and our repository still provides the older openexr-2.3.0 > (even if likely not used by krita users) besides >=2.5 where Pixar's module > seems to work. > > - Can we be sure it won't break in the future? > - Shouldn't ideally be ECM's module be fixed to work with Windows? Andreas, it'd be great if you could check with the module in my MR. Let me know if you find any errors.
Git commit 7699e8a1cb0d18751ad02fb786c0d15562a76e51 by Dmitry Kazakov, on behalf of L. E. Segovia. Committed on 19/09/2021 at 10:49. Pushed by dkazakov into branch 'master'. OpenEXR: upgrade our Find module Currently, we use Pixar's find module to manage OpenEXR 2, which cannot find either v2.3 and lower or v3. The suggestion in the bug report was to use ECM, which in turn has the following issues: * It completely ignores the versioned suffix that OpenEXR applies to its libraries; this implies that it's relying on Linux's symlinks to point it to the correct library. This is a blocker for any level of support for Windows. * Secondly, but also less serious, it doesn't cover the IexMath and IlmImfUtil subcomponents. This commit replaces our Find module with ECM's, and makes the following modifications. 1. Find and use any CMake config module that OpenEXR provides. 2. Failing that, construct the library suffix, and manually look up each component. 3. Add IexMath and IlmImfUtil to the list of libraries. 4. Add support for OpenEXR v3 and its list of components. Additionally, I've cleaned up our find and linking logic. CCMAIL: kimageshop@kde.org M +6 -14 CMakeLists.txt M +358 -74 cmake/modules/FindOpenEXR.cmake M +0 -3 libs/pigment/CMakeLists.txt M +0 -3 plugins/color/lcms2engine/CMakeLists.txt M +0 -4 plugins/impex/exr/CMakeLists.txt M +0 -3 plugins/impex/raw/CMakeLists.txt https://invent.kde.org/graphics/krita/commit/7699e8a1cb0d18751ad02fb786c0d15562a76e51
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/195