Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751951AbbGNE1O (ORCPT ); Tue, 14 Jul 2015 00:27:14 -0400 Received: from mail-ob0-f180.google.com ([209.85.214.180]:35021 "EHLO mail-ob0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751875AbbGNE1M (ORCPT ); Tue, 14 Jul 2015 00:27:12 -0400 MIME-Version: 1.0 In-Reply-To: <20150713004647.GA20148@huvuddator> References: <1436738358-19546-1-git-send-email-ulfalizer@gmail.com> <20150713004647.GA20148@huvuddator> Date: Tue, 14 Jul 2015 06:27:11 +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: 4167 Lines: 106 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'. 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 -- 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/