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

Thierry Reding thierry.reding at gmail.com
Mon May 19 06:11:01 PDT 2014


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?

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

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

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

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

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140519/0d00f57f/attachment.sig>


More information about the wayland-devel mailing list