XCB's Makefile.am has: vpath %.xml $(XCBPROTO_XCBINCLUDEDIR) $(XCBPROTO_XCBINCLUDEDIR)/extensions but this only works on GNU make. It should be replaced with something portable.
instead of using just one rule for the .h and .c, maybe 2 rules can solve the problem : %.h: $(XCBPROTO_XCBINCLUDEDIR)/%.xml c-client.xsl @n=`dirname $*`; test -d $$n || (echo mkdir $$n; mkdir $$n) $(XSLTPROC) --stringparam mode header \ --stringparam base-path $(XCBPROTO_XCBINCLUDEDIR)/ \ -o $@ $(srcdir)/c-client.xsl $< %.c: $(XCBPROTO_XCBINCLUDEDIR)/%.xml c-client.xsl @n=`dirname $*`; test -d $$n || (echo mkdir $$n; mkdir $$n) $(XSLTPROC) --stringparam mode source \ --stringparam base-path $(XCBPROTO_XCBINCLUDEDIR)/ \ -o $@ $(srcdir)/c-client.xsl $< extensions/%.h: $(XCBPROTO_XCBINCLUDEDIR)/extensions/%.xml c-client.xsl @n=`dirname $*`; test -d $$n || (echo mkdir $$n; mkdir $$n) $(XSLTPROC) --stringparam mode header \ --stringparam base-path $(XCBPROTO_XCBINCLUDEDIR)/ \ --stringparam extension-path \ $(XCBPROTO_XCBINCLUDEDIR)/extensions/ \ -o $@ $(srcdir)/c-client.xsl $< extensions/%.c: $(XCBPROTO_XCBINCLUDEDIR)/extensions/%.xml c-client.xsl @n=`dirname $*`; test -d $$n || (echo mkdir $$n; mkdir $$n) $(XSLTPROC) --stringparam mode source \ --stringparam base-path $(XCBPROTO_XCBINCLUDEDIR)/ \ --stringparam extension-path \ $(XCBPROTO_XCBINCLUDEDIR)/extensions/ \ -o $@ $(srcdir)/c-client.xsl $< It works for me (tm)
The whole %.foo notation is unsupported by vanilla make, sadly
Bart : and does something like : $(OBJECTS) : %.o :%.c ****** work ? It's in the documentation of GNU make. If not, except adding a rule for each file, I don't know what to do. Maybe looking a Makefile created by your automake and see how the Makefile manage the patterns
This looks like a job for a make default rule that does ".xml.c:" together with the appropriate dependencies.
Fixed with a quite ugly patch (commit 00ab1af3872dd1e987cd5fbc889517f9b27c122b) that explicitly names each .xml file in the proto tree and makes symlinks. Pretty clearly something better should be done, but this does close the bug for the moment.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.