[2021-03-17 11:15:26+0200] Mart Raudsepp:
> Ü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?
It has been in my overlay for a while (haven't included all the splitted
plugins though).
ie.
https://hacktivis.me/git/overlay/file/media-plugins/gst-plugins-hls/gst-plugins-hls-1.18.4.ebuild.html
> 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?
I think this particular one isn't solved yet. Mainly because it doesn't
seems to have caused me issues yet.
> Some other quick notes:
>
> * I would prefer this being EAPI-7 only
Yeah, as discussed in #gentoo-dev I'm doing this, pushed a WIP version in my
overlay if you want to take an early look.
> * Don't make nls optional
What's the reason for this? It's the case with gstreamer::gentoo.
> * 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?
Yeah, orc should be automatically added.
