[PATCH v3] configure.ac: Change in build system to use the path from pkg-config for wayland-scanner.

[Pekka Paalanen]

On Mon, 19 May 2014 15:11:01 +0200
Thierry Reding <thierry.reding at gmail.com> wrote:

> On Mon, May 19, 2014 at 01:39:24PM +0300, Pekka Paalanen wrote:
> > On Mon, 19 May 2014 11:56:39 +0200 Thierry Reding <thierry.reding at gmail.com> wrote:
> > > On Mon, May 19, 2014 at 11:59:51AM +0300, Pekka Paalanen wrote:
> > > > On Sun, 18 May 2014 00:39:16 +0200 Thierry Reding <thierry.reding at gmail.com> wrote:
> [...]
> > > > > I think it would further be useful to make all of that logic available
> > > > > via an m4 snippet (like what we already have in wayland-scanner.m4) so
> > > > > that all packages that need wayland-scanner handle this consistently.
> > > > > weston should use that snippet rather than implement its own version.
> > > > 
> > > > Actually that .m4 snippet has caused a lot of grief. Now, most projects
> > > > just don't bother with it. It is much easier and more flexible to just
> > > > copy the few lines that the wayland-scanner build rules need.
> > > 
> > > Unless something causes these rules to need modification, in which case
> > > all projects now need to adapt manually. I think if at least weston used
> > > that snippet there'd be enough regular testing to make sure nothing
> > > breaks. Otherwise if it's really causing too much grief to be useful by
> > > any project and if it can't be fixed, then perhaps a better option would
> > > be to remove it altogether.
> > 
> > One basic problem with this particular snippet is, that it cannot deal
> > with multiple locations for the XML files.
> 
> I think that may just be caused by the WAYLAND_PROTOCOLDIR definition.
> To get a better idea of what's needed I started to implement some of the
> ideas that I brought up and I have something that works at least for
> wayland and weston. Are there any other projects known that require this
> so I can check against more than this particular combination?

Hmm. I'm not sure even Weston really requires multiple protocol dirs.
It does not sure any extensions outside from what it itself defines,
and libwayland offer all core protocol in readily compiled form.

You'd need to find a project that uses both its own extensions and
someone else's extension without copying the someone else's XML file
into its own project. I'm not sure there are any yet.

Especially as Weston does not even install the XML files of its
extensions. Maybe another thing to fix, but may need to reconsider the
names in the extensions, as Weston extensions are mostly waiting to
stabilize, or are just private.

> > It also used to produce mysterious error messages, when when the macro
> > wasn't really found or something else was missing.
> > 
> > Grepping Weston for WAYLAND_SCANNER_RULES or wayland-scanner.mk produces
> > nothing, so looks like it is already abandoned by Weston.
> > 
> > The wayland-scanner.m4 insists for the .pc file to give the absolute
> > path to wayland-scanner, with no way to override AFAICS.
> 
> Part of the bigger plan was to come up with a sound sequence to look up
> the wayland-scanner binary and provide it in wayland-scanner.m4. That
> way it could be turned into the standard method for all packages that
> need the wayland-scanner (and wayland-scanner.mk).

The major problem there was the wayland-scanner.mk part. That is
probably best left out, but finding wayland-scanner would be nice as an
autoconf macro.

> > > That still leaves open the question of how to handle stale versions of
> > > the wayland-scanner binary. Like I said, I think telling people to add
> > > it to the PATH wouldn't be much of a burden. For many users that might
> > > already be the case anyway. For instance I have a set of scripts to
> > > cross-build distributions from scratch (similar in spirit to buildroot
> > > and friends) where tools such as wayland-scanner get installed to a
> > > prefix that's always first in PATH. When I do native builds out of git
> > > I usually install to /usr/local/stow/$PACKAGE and let stow manage the
> > > symlink hierarchy in /usr/local for me. The distribution that I use has
> > > /usr/local/bin in PATH (so that it takes precedence over /usr/bin), so
> > > any binaries that I install manually override whatever the distribution
> > > installed.
> > > 
> > > If the exact version of wayland-scanner really matters, perhaps a better
> > > solution would be to check for the required version at configure time.
> > 
> > Ok, we can also just ignore that little problem. I'm not sure how you
> > would check the wayland-scanner version. You can't use the .pc file,
> > and wayland-scanner itself cannot tell you.
> 
> I suppose it could be made to report the version when passed a -V
> (--version) option and some clever shell code could be used to parse
> that. I'm not very fond of that type of thing myself, though, since I've
> seen it break all too often.

It would still hit old versions of wayland-scanner that do not
recognize -V. Otherwise it would be a good idea.

> > Good thing it is not
> > supposed to be version-picky even though there are some rare failure
> > modes (too new wayland-scanner with old libwayland, or too old
> > wayland-scanner not supporting the latest XML mark-up).
> 
> Will those result in build failures or silently corrupt parts of the
> build process? In the former I guess it would be fine because users
> would be forced to investigate anyway and should be able to figure it
> out if the build instructions make sure to mention updating the PATH.

I think they are always build failures. But they may leave empty or
incomplete files behind, which make the next build attempt fail
mysteriously.

> > Will you take Hebbar's patch review to the end?
> 
> I can do that. I have a pair of local patches to wayland and weston that
> solve the problem for me and they are rather large and more involved to
> what Hebbar posted. I'll clean them up a little (and perhaps try to
> split them into smaller independent chunks) and send them out to make
> the discussion a little more tangible.

Ok, thanks!
pq