[RFC] webp: switch recipe to cmake buildsystem

Besides the improvements that cmake offers compared to autotools,
the advantage would be that cmake config files get created.
This is useful so that other projects can find webp using cmake.

Remove EXTRA_OECONF settings because all of them are set like this
by default.

CMakeLists.txt doesn't provide an option for selecting neon but from
what I have tested it gets selected properly.

Downside is that there is no way to deactivate gif,jpeg,tiff,png or
opengl. The libraries are used whenever they are pulled into the sysroot.

Signed-off-by: Markus Volk <f_l_k@t-online.de>
---
 meta/recipes-multimedia/webp/libwebp_1.3.2.bb | 35 +++++--------------
 1 file changed, 9 insertions(+), 26 deletions(-)

On Tue, 2024-01-09 at 14:28 +0100, Markus Volk wrote:
> Besides the improvements that cmake offers compared to autotools,
> the advantage would be that cmake config files get created.
> This is useful so that other projects can find webp using cmake.
> 
> Remove EXTRA_OECONF settings because all of them are set like this
> by default.
> 
> CMakeLists.txt doesn't provide an option for selecting neon but from
> what I have tested it gets selected properly.
> 
> Downside is that there is no way to deactivate gif,jpeg,tiff,png or
> opengl. The libraries are used whenever they are pulled into the sysroot.

I don't really mind cmake or not but we do care a lot about
determinism. 

The trouble is things can end up in the sysroot via indirect
dependencies so this change allows unintended changes to creep in (a
dependency adds jpeg so the config of webp could change too). I'm
therefore not happy about having "floating" dependencies this
introduces.

Could we submit a patch upstream to avoid floating dependencies and
allow things to be specific?

Cheers,

Richard

On Tue, 9 Jan 2024 at 15:10, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> The trouble is things can end up in the sysroot via indirect
> dependencies so this change allows unintended changes to creep in (a
> dependency adds jpeg so the config of webp could change too). I'm
> therefore not happy about having "floating" dependencies this
> introduces.
>
> Could we submit a patch upstream to avoid floating dependencies and
> allow things to be specific?

I checked the source code. Checking the presence of gif/png/jpeg/tiff
libraries is conditional on WEBP_FIND_IMG_LIBS being true, and that
variable is set thusly:

# Include dependencies.
if(WEBP_BUILD_ANIM_UTILS
   OR WEBP_BUILD_CWEBP
   OR WEBP_BUILD_DWEBP
   OR WEBP_BUILD_EXTRAS
   OR WEBP_BUILD_GIF2WEBP
   OR WEBP_BUILD_IMG2WEBP)
  set(WEBP_FIND_IMG_LIBS TRUE)
else()
  set(WEBP_FIND_IMG_LIBS FALSE)
endif()

So perhaps we can add PACKAGECONFIG for all six of these WEBP_BUILD
things, and each would include the full set of image libraries as
dependencies.

The opengl dependency is needed only if WEBP_BUILD_VWEBP is set to
true, so that would be another PACKAGECONFIG.

This would avoid the need for new cmake options, but we would still
need a patch to turn floating library dependencies into hard ones
subject to the existing options listed above being enabled.

Alex

On Tue, Jan 9 2024 at 02:10:10 PM +00:00:00, Richard Purdie 
<richard.purdie@linuxfoundation.org> wrote:
> The trouble is things can end up in the sysroot via indirect
> dependencies so this change allows unintended changes to creep in (a
> dependency adds jpeg so the config of webp could change too). I'm
> therefore not happy about having "floating" dependencies this
> introduces.

Yes, this actually happens and also triggered me, that's why I 
mentioned it.
The issue for me is, that this is google code and google would force me 
to create/use a google account even to contact them.
Therefore I feel strongly uninvited there.

I tried to resolve the issue and sent a v2. But for the above reason I 
won't be taking the patch to google