[PATCH] doc: Quell warnings about missing man3 directory before its been built

[Peter Hutterer]

sorry about the delay, was on holidays.

On Fri, Jul 25, 2014 at 04:30:41PM +0300, Pekka Paalanen wrote:
> On Mon, 21 Jul 2014 19:23:49 +0000
> "Bryce W. Harrington" <b.harrington at samsung.com> wrote:
> 
> > The shell command for dist_man3_MANS gets invoked several times during
> > the make process but before the man pages have been generated, which
> > causes the following warnings when running `make`:
> > 
> >     find: `man/man3': No such file or directory
> >     find: `man/man3': No such file or directory
> >     find: `man/man3': No such file or directory
> >       GEN    xml/client/index.xml
> > 
> > Despite these error messages, the generated dist tarball contains the
> > man3 pages as intended, both before and after this patch.
> > 
> >     $ make dist
> >     $ tar xxf wayland-1.5.90.tar.xz
> >     $ find wayland-1.5.90/doc/doxygen/man/man3 -name "wl_*.3" | wc -l
> >     85
> > 
> > Signed-off-by: Bryce Harrington <b.harrington at samsung.com>
> > ---
> >  doc/doxygen/Makefile.am |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/doc/doxygen/Makefile.am b/doc/doxygen/Makefile.am
> > index de3b31f..83622af 100644
> > --- a/doc/doxygen/Makefile.am
> > +++ b/doc/doxygen/Makefile.am
> > @@ -20,7 +20,7 @@ scanned_src_files_server = 				\
> >  # find all man/man3/wl_foo.3 pages
> >  # for this to work, we need to create them before the man target (hence
> >  # all-local below)
> > -dist_man3_MANS= $(shell find man/man3/ -name "wl_*.3" -printf "man/man3/%P\n")
> > +dist_man3_MANS = $(shell test -d man && find man/man3 -name "wl_*.3" -printf "man/man3/%P\n")
> >  
> >  xml/client/index.xml: $(scanned_src_files_client) wayland.doxygen
> >  	$(AM_V_GEN)$(MKDIR_P) xml/client && \
> 
> Yeah, I see it and there are lots of those during 'make distcheck', but
> I wonder, is this the right fix? Peter?

I think it's the right fix. there may be some trickery to avoid all this but
I haven't figured out what it is.

Cheers,
   Peter

> 
> Also, it seems this particular line really depends on the recursive
> make, as the first evaluation would not produce the intended value. Ah,
> so it was: 509d1d802abda4cec5a22fab5848787f92f69f02
> 
> 
> Thanks,
> pq