Move all cmake/Find*.cmake files to extra-cmake-modules and add that as a dependency

[eszlari]

https://invent.kde.org/frameworks/extra-cmake-modules

"While the driving force of this module is to reduce duplication in CMake scripts
across KDE software, it is intended to be useful for any software that uses the
CMake build system."

CC @jlskuz

[jlskuz]

It sounds like a good idea to me, but as a KDE developer I am of course very biased.

While it would be easy to use in the Kdenlive build scripts (because we use it already anyways). It will be an extra piece for Shotcut and co. That's why I don't want to push too hard on it and go with whatever @ddennedy decides.

Some things to take into consideration:

• ECM is lightweight in the sense that it does not have dependencies on other software
• ECM will be a build time dependency only
• If we upstream files to ECM it will take several months or years until a release including them is populated to all relevant distributions such as Ubuntu LTS. So this will be a long-term project.
• For FindFFmpeg.cmake there is already a merge request open
• Other features besides the find modules such as https://api.kde.org/ecm/kde-module/KDEGitCommitHooks.html might be useful for MLT too

[ddennedy]

I am open to it after this set of changes has settled. It might be preferable to add it as git submodule.

[bmatherly]

I agree that git submodule might be the best. But I don't like the idea that other people might be hacking on the Find*.cmake files that we depend on. One day i will update my repository and my build will fail because someone changed a find file in a way that is incompatible with how we are using it. Maybe some files are "standard" and should be shared. Maybe others are custom to Shotcut (like FindClangFormat.cmake).

[jlskuz]

Maybe some files are "standard" and should be shared. Maybe others are custom to Shotcut (like FindClangFormat.cmake).

Yes, it might not make sense for everything to be shared, but luckily it is possible to have a hybrid approach.

But I don't like the idea that other people might be hacking on the Find*.cmake files that we depend on. One day i will update my repository and my build will fail because someone changed a find file in a way that is incompatible with how we are using it.

ECM is part of KDE Frameworks which means it promises API stability. So if this happens it means you are a) either using it wrong b) there's a bug in ECM

[eszlari]

If we upstream files to ECM it will take several months or years until a release including them is populated to all relevant distributions such as Ubuntu LTS. So this will be a long-term project.

For Flatpak, Snap, AppImage this should not matter.

[jlskuz]

The flatpak runtime does already contain ECM so that shouldn't be relevant, however many distro packagers also use a similar network-restricted environment. As we experienced in Kdenlive with OTIO recently they don't like FetchContent very much.

For a developer setup FetchContent or a submodule might work though.

[eszlari]

FetchContent supports an offline workflow, see FETCHCONTENT_SOURCE_DIR_*:

https://cmake.org/cmake/help/latest/module/FetchContent.html#variable:FETCHCONTENT_SOURCE_DIR_%3CuppercaseName%3E

[eszlari]

I ran into this with SVT-AV1.

I was able to build git master without internet connection. I guess it was this MR that fixed it by removing cpuinfo:

https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/2453

You should have been able to fix it back then with:

cmake -D FETCHCONTENT_SOURCE_DIR_CPUINFO=/path/to/cpuinfo

[ddennedy]

Git master and latest release removed external cpuinfo but now FFmpeg 7.1 is not compatible with it. Feel free to fix it. I have better things to do than babysit builds.

[eszlari]

now FFmpeg 7.1 is not compatible with it

For build fixes I look at how distros do it, Arch Linux is usually very up-to-date:

https://gitlab.archlinux.org/archlinux/packaging/packages/ffmpeg/-/commit/ec5a8098b093a226abbaecff7fc9e6bb64f8dab5

[jlskuz]

Yet another aspect to consider is, that maybe glaxnimate will require ECM too if we want to use upstream's CMake files instead of maintaining customer ones here. However it is probably too early to discuss this in detail now, the glaxnimate update is one of the next things on my todo list after MSVC.