[PATCH 2/5] Remove wayland_protocoldir definition

Thierry Reding thierry.reding at gmail.com
Tue May 27 00:49:28 PDT 2014


On Tue, May 27, 2014 at 09:43:09AM +0300, Pekka Paalanen wrote:
> On Mon, 19 May 2014 17:12:40 +0200
> Thierry Reding <thierry.reding at gmail.com> wrote:
> 
> > From: Thierry Reding <treding at nvidia.com>
> > 
> > This is mostly useless and can be confusing in makefiles. The pattern
> > rules defined in the makefile snippet are generic enough to allow the
> > protocol sources to reside in subdirectories.
> > 
> > Signed-off-by: Thierry Reding <treding at nvidia.com>
> > ---
> >  wayland-scanner.m4 | 2 --
> >  wayland-scanner.mk | 6 +++---
> >  2 files changed, 3 insertions(+), 5 deletions(-)
> > 
> > diff --git a/wayland-scanner.m4 b/wayland-scanner.m4
> > index 4e4222ad4d2f..e7f383a4c74f 100644
> > --- a/wayland-scanner.m4
> > +++ b/wayland-scanner.m4
> > @@ -8,6 +8,4 @@ AC_DEFUN([WAYLAND_SCANNER_RULES], [
> >  
> >      wayland_scanner_rules=`$PKG_CONFIG --variable=pkgdatadir wayland-scanner`/wayland-scanner.mk
> >      AC_SUBST_FILE([wayland_scanner_rules])
> > -
> > -    AC_SUBST([wayland_protocoldir], [$1])
> >  ])
> > diff --git a/wayland-scanner.mk b/wayland-scanner.mk
> > index 0a72062baa59..b6e0f444aaa5 100644
> > --- a/wayland-scanner.mk
> > +++ b/wayland-scanner.mk
> > @@ -1,8 +1,8 @@
> > -%-protocol.c : $(wayland_protocoldir)/%.xml
> > +%-protocol.c: %.xml
> >  	$(AM_V_GEN)$(wayland_scanner) code < $< > $@
> >  
> > -%-server-protocol.h : $(wayland_protocoldir)/%.xml
> > +%-server-protocol.h: %.xml
> >  	$(AM_V_GEN)$(wayland_scanner) server-header < $< > $@
> >  
> > -%-client-protocol.h : $(wayland_protocoldir)/%.xml
> > +%-client-protocol.h: %.xml
> >  	$(AM_V_GEN)$(wayland_scanner) client-header < $< > $@
> 
> I think the original purpose here was, that the .xml was not in the
> same directory as where you wanted to put the generated .c and .h files.
> For instance, Weston could install some .xml files to the system, and a
> third party project would then generate the C code from them.

That's for cases where some packages provided a set of standard
protocols that some other package would want to implement?

> Would that still work?

I don't think it would. But if you set wayland_protocoldir to some
absolute path it will prevent any such package from providing its own
set of protocol files and use the same make snippet since those rules
will then only look at the absolute wayland_protocoldir but not inside
the source tree.

So I think shipping a common snippet will either be able to support one
or the other use case, but not both at the same time.

> And out-of-tree builds?

For out-of-tree builds the above still works because srcdir is added to
the VPATH automatically and therefore make will find the protocol files
there.

> Another thing is, I'm not sure we can change these?
> 
> wayland-scanner.mk and wayland-scanner.m4 are installed files, and I'm
> so unclear of what guarantees we have for them. They are used for build
> only, so I suppose dependent projects test for the minimum libwayland
> version, but I think we need to maintain backward compatibility.
> 
> OTOH, I still think that we should drop wayland-scanner.mk completely.
> Can we do that? Both Weston and Mesa just open-code what
> wayland-scanner.mk would have provided, because wayland-scanner.mk was
> inconvenient to use.

Like you said, it doesn't seem like these are currently used by anyone
so there isn't much opportunity to break anything. In fact the whole
reason for this series was to make the m4/mk files more usable so that
other projects could use them.

> The rest of this series pretty much depends on the decision here.
> 
> How about the following:
> - keep the existing wayland-scanner.{mk,m4} as is
> - add warnings to both that they will be going away after a few
>   wayland releases, so that they will yell at build time
> - add a new .m4 file for what you have in patch 3
> - patch 3 should provide two things:
>   * set WAYLAND_SCANNER to the exectable
>   * set another variable to the directory of the installed .xml files?
> 
> Then after enough time passes, we could just remove
> wayland-scanner.{mk,m4} as per the warning/threat.

I'm not too thrilled by the idea of having everyone using their own copy
of the makefile snippets, but as discussed above I don't see a way to
make it work for the general case, so maybe it's not worth it.

FWIW, I don't think we necessarily need to remove wayland-scanner.m4.
The interface isn't changed and we can mark the makefile snippet as
deprecated using $(warning ...) for example. Then once nobody's using
the makefile snippet any longer we can simply remove the m4 pieces that
set it up along with the snippet itself.

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/20140527/cd3eba24/attachment-0001.sig>


More information about the wayland-devel mailing list