Double-checking the correct way to find wayland-scanner

[Jussi Kukkonen]

On 18 May 2017 at 15:57, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> 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 think I agree here: It's better to make the few people who cross-compile
do the unexpected thing than it is to make everyone else do it.


> 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?
>

What you suggest below is pretty common I think. Many projects seem to have
similar difficulties though (gobject-introspection comes to mind but I
believe in that case common introspection.m4 made things a little easier --
not so many things to patch).

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.
>

So a "--with-wayland-scanner" configure option. Sounds fine to me. It adds
a new configure option to every wayland using project but arguably so did
my proposal... Unless new opinions appear I'll make patches for weston and
mesa to maybe get more tangible comments.


Thanks,
Jussi

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
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20170518/b7ee12bf/attachment.html>