Double-checking the correct way to find wayland-scanner

[Pekka Paalanen]

On Thu, 18 May 2017 13:59:25 +0300
Jussi Kukkonen <jussi.kukkonen at intel.com> wrote:

> Hi,
> 
> I'd like to fix/standardize how several wayland using projects do
> wayland-scanner lookups (because many of them require patching when
> cross-compiling in Yocto) and wanted to double check that I'm arguing for
> the right thing...
> 
> The problem cases for us are like this mesa example:
> 
> > PKG_CHECK_MODULES([WAYLAND_SCANNER], [wayland-scanner],
> >         WAYLAND_SCANNER=`$PKG_CONFIG --variable=wayland_scanner  
> wayland-scanner`,
> >         WAYLAND_SCANNER='')
> > if test "x$WAYLAND_SCANNER" = x; then
> >     AC_PATH_PROG([WAYLAND_SCANNER], [wayland-scanner], [:])
> > fi  
> 
> This is a problem if pkg-config returns finds a wayland-scanner but it is
> not the wayland-scanner we want to use (in Yocto case the path will be
> target wayland-scanner path).
> 
> Weston on the other hand handles this in an order that's fine for Yocto:
> 
> > AC_PATH_PROG([wayland_scanner], [wayland-scanner])
> > if test x$wayland_scanner = x; then
> >         PKG_CHECK_MODULES(WAYLAND_SCANNER, [wayland-scanner])
> >         wayland_scanner=`$PKG_CONFIG --variable=wayland_scanner  
> wayland-scanner`
> > fi  
> 
> I can imagine that this order might be problematic for some use cases (?),
> but at least the AC_PATH_PROG value can be overridden.
> 
> My proposal is to try to standardize on Weston style with the addition of
>     AC_ARG_VAR([wayland_scanner], [The wayland-scanner executable])
> To make it clear "wayland_scanner" can be overridden -- this is essentially
> what wayland-protocols does.
> 
> Thoughts?

Hi Jussi,

it's a bit awkward problem.

The obvious caveat of Weston style is that if you have wayland-scanner
installed in your system, and you are building another version into a
$prefix, you must set PATH to find things in $prefix or they will
silently use the system version. This is problematic, because sometimes
(rarely) the scanner changes and it is assumed that the scanner matches
the libwayland you are building for. So, casual contributors can easily
shoot their foot in Weston style, while in Mesa style they get the
right one automatically - the one pkg-config is pointing to. But
Mesa style won't work for cross-builds.

I recall debating this with Emil, CC'd.

I feel that there is a fundamental problem behind all this: project A
builds a tool that project B needs for its build. If both projects are
cross-compiled for host arch, where and how would project A install the
tool built for the build arch, and how would project B find it?

How do other projects handle it?

Your suggestion sounds good. How about:
- if the configure variable is set, use it
- otherwise PKG_CHECK_MODULES and check that the tool can run
- and if that fails, fail the build with a nice error message.

We would never look in PATH, so it would be unlikely to unexpectedly
pick up the system installed version. The configure variable is the
override that cross-build environments must use. PKG_CHECK_MODULES will
pick up the same scanner as the libwayland.

Maybe we should also stop installing wayland-scanner in PATH? There is
already the .pc file to point to it.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20170518/19e8680b/attachment.sig>