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