[Mesa-dev] [PATCH] configure.ac: Add --with-wayland-scanner-path

[Emil Velikov]

On 26 May 2017 at 14:55, Jussi Kukkonen <jussi.kukkonen at intel.com> wrote:
> On 26 May 2017 at 14:32, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>
>> On 26 May 2017 at 08:52, Jussi Kukkonen <jussi.kukkonen at intel.com> wrote:
>> >
>> >
>> > On 24 May 2017 at 16:39, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> >>
>> >> Hi Jussi,
>> >>
>> >> On 23 May 2017 at 09:13, Jussi Kukkonen <jussi.kukkonen at 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.
>
I'm confused a bit - did you try the above suggestions? If so can you
share which one and how it fails?

I do see your interest in having a native sysroot dir, although I am a
bit suspicious that you need it in the first place.

-Emil