Re: [gentoo-dev] [PATCH] gstreamer-meson.eclass: New eclass required for gstreamer-1.18.0+

[Mart Raudsepp <leio@gentoo.org>]

Thanks for working on this, some very initial comments below

Ühel kenal päeval, K, 17.03.2021 kell 01:57, kirjutas Sam James:
> > +# @FUNCTION: gstreamer_multilib_src_install_all
> > +# @DESCRIPTION:
> > +# Installs documentation for requested gstreamer plugin, and
> > removes
> .la
> > +# files.
> > +gstreamer_multilib_src_install_all() {
> > +	local plugin_dir
> > +
> > +	for plugin_dir in ${GST_PLUGINS_BUILD_DIR} ; do
> > +		local dir=$(gstreamer_get_plugin_dir
> > ${plugin_dir})
> > +		[[ -e ${dir}/README ]] && dodoc "${dir}"/README
> > +	done
> > +
> > +	prune_libtool_files --modules
> 
> Deprecated in newer EAPIs, let’s do it manually.

I don't think that ought to be necessary at all, as a meson build
wouldn't be generating libtool files.


My main initial question on this version is:
How does it behave with helper libraries from the same tarball?

Basically what gstreamer_system_link function solved in the autotools
eclass.
E.g., if you build gst-plugins-libvisual, is it building gstreamer-
audio, gstreamer-video and gstreamer-pbutils as well again
(automatically due to generated ninja dependencies), or picks them up
from gst-plugins-base?

Some other quick notes:

* I would prefer this being EAPI-7 only
* Don't make nls optional
* It would be neat if we had a QA warning when a split plugin uses orc,
but doesn't have in IUSE for it (or vice-versa); maybe that's doable by
checking if the plugin meson.build uses orc_dep?


Mart