Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751893AbbGNEfo (ORCPT ); Tue, 14 Jul 2015 00:35:44 -0400 Received: from mail-ob0-f178.google.com ([209.85.214.178]:34286 "EHLO mail-ob0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751221AbbGNEfn (ORCPT ); Tue, 14 Jul 2015 00:35:43 -0400 MIME-Version: 1.0 In-Reply-To: References: <1436738358-19546-1-git-send-email-ulfalizer@gmail.com> <20150713004647.GA20148@huvuddator> Date: Tue, 14 Jul 2015 06:35:42 +0200 Message-ID: Subject: Re: [PATCH] DocBook: Avoid stdout junk with no man pages to compress From: Ulf Magnusson To: Jim Davis Cc: linux-kernel , linux-doc , Michal Marek , Jonathan Corbet , Herbert Xu , smueller@chronox.de, Ulf Magnusson Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4546 Lines: 114 On Tue, Jul 14, 2015 at 6:27 AM, Ulf Magnusson wrote: > On Mon, Jul 13, 2015 at 2:46 AM, Ulf Magnusson wrote: >> On Sun, Jul 12, 2015 at 04:36:53PM -0700, Jim Davis wrote: >>> On Sun, Jul 12, 2015 at 2:59 PM, Ulf Magnusson wrote: >>> > gzip would run as 'gzip -f' when no uncompressed man pages were found, >>> > making it compress the (empty) stdin to stdout. >>> >>> > --- a/Documentation/DocBook/Makefile >>> > +++ b/Documentation/DocBook/Makefile >>> > @@ -56,7 +56,7 @@ htmldocs: $(HTML) >>> > >>> > MAN := $(patsubst %.xml, %.9, $(BOOKS)) >>> > mandocs: $(MAN) >>> > - find $(obj)/man -name '*.9' | xargs gzip -f >>> > + find $(obj)/man -name '*.9' -exec gzip -f {} \; >>> > >>> > installmandocs: mandocs >>> > mkdir -p /usr/local/man/man9/ >>> >>> That does get rid of the binary burp, but 'xargs gzip -f' has been in >>> the Makefile since January, and gzipping '\n' just started recently. >>> So what's changed? >>> >> >> No idea. I just assumed it had been broken since then, since the version >> before d56fcf299fb4 (DocBook: Do not exceed argument list limit) looked >> for *.9 files before running gzip: >> >> mandocs: $(MAN) >> $(if $(wildcard $(obj)/man/*.9),gzip -f $(obj)/man/*.9) >> >>> It looks like, for whatever reason, make installmandocs always ends up >>> rerunning mandocs -- there's now a 'GEN Documentation >>> Docbook//v4l2.xml' printed, and that extra mandocs invocation is where >>> the problematic second invocation of find is coming from. I won't >>> pretend to understand the Makefile flow to guess at why that's >>> happening, but obviously 'make mandocs; make installmandocs' shouldn't >>> need to regenerate things already generated. >> >> I won't pretend to understand the Makefile flow either. Guess it might >> be worth looking into v4l2.xml as well then. Could be some directory >> shenanigans going on judging from the '//'. >> > > I looked into it some more, and I'm now fairly certain that 'mandocs' always > runs its recipe regardless of the status of the prerequisites. Changing the > top-level Makefile to do > > $(Q)$(MAKE) --debug=v $(build)=Documentation/DocBook $@ > > and running 'make mandocs', you see some FORCEs in the output, which -- unless > my make fu is weak -- causes all the targets above that to always be considered > out of date: > > File 'mandocs' does not exist. > Considering target file 'Documentation/DocBook/z8530book.9'. > Considering target file 'Documentation/DocBook/z8530book.xml'. > ... > Considering target file 'FORCE'. > File 'FORCE' does not exist. > Finished prerequisites of target file 'FORCE'. > Must remake target 'FORCE'. > Successfully remade target file 'FORCE'. > ... > Must remake target 'Documentation/DocBook/z8530book.xml'. > ... > Must remake target 'mandocs'. Had forgotten that 'mandocs' is a phony target too. That alone makes it always run its recipe when it's a prerequisite of some target that's run. > > > Re. the 'GEN Documentation Docbook//v4l2.xml', I think the problem is the > following rule in Documentation/DocBook/media/Makefile: > > $(MEDIA_OBJ_DIR)/v4l2.xml: $(OBJIMGFILES) > @$($(quiet)gen_xml) > @(ln -sf `cd $(MEDIA_SRC_DIR) && /bin/pwd`/v4l/*xml $(MEDIA_OBJ_DIR)/) > @(ln -sf `cd $(MEDIA_SRC_DIR) && /bin/pwd`/dvb/*xml $(MEDIA_OBJ_DIR)/) > > ./Documentation/DocBook/v4l2.xml is a symlink, so make compares the > modification time of the symlink *target* (which is never updated) against the > image (*.png, *.gif, etc.) files in $(OBJIMGFILES). Updating the symlink itself > won't change that modification time, so that's why it always runs. > > Passing --check-symlink-times to make so that it also looks at the modification > time of the symlink seems to change a bunch of other stuff in the output too. > Maybe there's other problems lurking here as well. > >>> >>> In any event, >>> >>> Tested-by: Jim Davis >>> >>> Jim >> >> I just noticed the commit message only mentions the alternative >> solutions and not the implemented solution. Could send a v2 that fixes >> that, but I'll wait for more comments first. >> >> Cheers, >> Ulf > > Cheers, > Ulf Cheers, Ulf -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/