On 26 May 2017 at 14:32, Emil Velikov <emil.l.veli...@gmail.com> wrote:
>
> On 26 May 2017 at 08:52, Jussi Kukkonen <jussi.kukko...@intel.com> wrote:
> >
> >
> > On 24 May 2017 at 16:39, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> >>
> >> Hi Jussi,
> >>
> >> On 23 May 2017 at 09:13, Jussi Kukkonen <jussi.kukko...@intel.com>
wrote:
> >> > Modify wayland-scanner lookup: Use the path given by pkg-config
> >> > but offer an option to override the path with
> >> > "--with-wayland-scanner-path=PATH". The latter is useful for
> >> > cross-compile situations.
> >> >
> >> > AC_PATH_PROG is no longer used (if the scanner is installed it should
> >> > get found by pkg-config). AC_SUBST is added so the output variable is
> >> > created when only the configure option is used.
> >> > ---
> >> >
> >> > My goal is to standardize wayland-scanner usage in a way that does
not
> >> > require patching when cross-compiling in Yocto (the detailed issue is
> >> > that in Yocto pkg-config will return a "wayland_scanner" variable but
> >> > that will contain a _target path_ when we would like to use a native
> >> > sysroot path instead).
> >> >
> >> > I've sent a similar patch to weston and intend to fix other projects
> >> > if these two patches are well received.
> >> >
> >> I might have misread something, but on a quick look the patch does not
> >> look quite right. Stepping aside for a moment,
> >>
> >> Can you explain clearly what's happening/wrong in the whole scenario?
> >> - Yocto does has A stage where it does X.
> >> - Then it proceeds to B... at which point $file
> >> foo/wayland-scanner.pc gets picked
> >> - That results in an error due to variable containing $bar, due to
> >> the $step above
> >
> > Hi Emil,
> >
> > I'm hoping this is a coherent enough explanation of the issue...
> >
> > When yocto cross-compiles mesa for target, we already have
> > a) All dependency headers and libraries in a target sysroot
> > b) Native wayland-scanner in a native sysroot
> >
> > The problem as I see it is that there is no way to express the _native_
> > sysroot in pkg-config: PKG_CONFIG_SYSROOT_DIR and pc_sysroot_dir
logically
> > refer to the target sysroot. So when mesa configure does "pkg-config
> > --variable=wayland_scanner wayland-scanner" it gets a reasonable
> > "/usr/bin/wayland-scanner" response: this would be the correct path to
> > wayland-scanner on _target_. In the best case this fails during compile
when
> > the scanner isn't found but unfortunately /usr/bin/wayland-scanner is
often
> > also a valid path to _host_ wayland-scanner which might be from a
completely
> > different and unrelated wayland version...
> >
> Barring an important s/pkg-config/$PKG_CONFIG/ I think I agree here.
>
> AFAICT there are a couple of alternative solutions - have you
> considered/tried any of them?
>
> a) w/o a wrapper script
> $ export PKG_CONFIG_PATH= // you need this if using the system
> pkgo-config. if the local/native one is used, this should be optional
> $ export
PKG_CONFIG_LIBDIR=$path_to_non_system_host_pkgconfig:${SYSROOT}/usr/{lib,share}/pkgconfig
> $ export PKG_CONFIG_SYSROOT_DIR=${SYSROOT}
We're using a natively built pkg-config which sets all the pkg-config
variables to what I believe are the correct values: the problem is that
none of those variable is for the _native_ sysroot location so they don't
help in this case. There is now way to say in a .pc file that this path
should be prefixed with something like "${pc_native_sysroot_dir}" if it's
defined.
> b) with a wrapper script - see [1].
> I think that the "export PKG_CONFIG_DIR=" is a typo (should be ..PATH
> instead) and is not strictly required - feel free to check either way.
> Note that the exec at the end might need to be amended to
> /path/to/$(CHOST)-pkg-config.
We don't provide a target wrapper -- I believe because it provides no value
at all on top of the setup we have (the pkg-config that autotools finds has
all the environment variables set correctly. It is essentially
$(CHOST)-pkg-config already).
If I've missed something, I'd be happy to hear that. At the moment I think
pkg-config just does not help in this case.
Thanks,
Jussi
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
