On Sun, 2025-03-09 at 06:27 -0400, Ionen Wolkens wrote:
> On Sun, Mar 09, 2025 at 10:17:42AM +0000, James Le Cuirot wrote:
> > > +ffmpeg_compat_setup() {
> > > + (( ${#} == 1 )) || die "Usage: ${FUNCNAME} <slot>"
> > > +
> > > + local path=${SYSROOT}$(ffmpeg_compat_get_prefix "${1}")
> > > + [[ ${PKG_CONFIG_PATH} =~ (.*)"${path}"/[^/]+/pkgconfig:(.*) ]] &&
> > > + PKG_CONFIG_PATH=${BASH_REMATCH[1]}${BASH_REMATCH[2]}
> > > + export
> > > PKG_CONFIG_PATH=${path}/$(get_libdir)/pkgconfig:${PKG_CONFIG_PATH}
> > > +}
> > > +
> > > +fi
> >
> > I like this approach. We've generally been quite good at dragging upstreams
> > to
> > the latest, so it would be a shame to go fully slotted.
> >
> > The regex check seems like overkill to me, but perhaps I've missed
> > something.
>
> Well, guess could let the multilib paths accumulate given it'll try
> the first one anyway. It was just cleaning up the previous one that it
> shouldn't use.
> That's what I thought. I don't mind too much. > > This currently won't work when cross-compiling as cross-pkg-config currently > > unsets PKG_CONFIG_PATH, but I have been thinking about changing that. That > > was > > done to tame non-Gentoo environments, but no one else uses crossdev in > > reality. > > Really? There's a few others eclasses that set PKG_CONFIG_PATH.. does > nothing work? Seems like things I haven't generally tried to cross-compile.
signature.asc
Description: This is a digitally signed message part
