All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Kuzminsky <seb@highlab.com>
To: git@vger.kernel.org
Subject: Re: [PATCH] Fix and clean up man page building
Date: Fri, 20 May 2005 11:09:57 -0600	[thread overview]
Message-ID: <E1DZB0X-0004qW-QX@highlab.com> (raw)
In-Reply-To: <20050520145211.GB27395@diku.dk>

Jonas Fonseca <fonseca@diku.dk> wrote:
> Raja R Harinath <rharinath@novell.com> wrote Fri, May 20, 2005:
> > Jonas Fonseca <fonseca@diku.dk> writes:
> > > +%.7 : %.1
> > > +	# FIXME: this next line works around an output filename bug in asciidoc 6.0.3
> > > +	if [ -f "$<" ]; then mv $< $@; fi
> > > +
> > >  %.1 %.7 : %.xml
> > >  	xmlto man $<
> > > -	# FIXME: this next line works around an output filename bug in asciidoc 6.0.3
> > > -	[ "$@" = "git.7" ] || mv git.1 $@
> > >  
> > >  %.xml : %.txt
> > >  	asciidoc -b docbook -d manpage $<
> > 
> > That doesn't look right.  I think you want
> > 
> >   %.7: %.xml
> >       xmlto man %<
> >
> >   %.1: %.xml
> >        xmlto man $<
> >        [ test -f $@ ] || mv git.1 $@
> 
> [ Looks like you mixed up %.1 and %.7 ]
> 
> Yes, separating the rule for %.1 and %.7 might be clearer. But it would
> be great if it would work for any man page in section 7 not just git.7.
> Since I hope to add cogito.7 soon.


That's still not right.  Jonas' %.7 target works (as long as none of the
%.7 source files have dashes in the name), but the %.1 target fails to
rebuild the manpages if they already exist.


The underlying problem, just so we're all clear, is that asciidoc 6.0.3
has a bug that causes it to output buggy xml files when the command-name
has a dash in it.  When there's a dash in the command-name, asciidoc
produces xml that says everything _before_ the first dash is the command
name, and everything _after_ the first dash is the quick description
("purpose") of that command.


The git.txt -> git.xml transition is fine since there is no dash in "git",
but (for example) the git-cat-file.txt -> git-cat-file.xml transition
tickles the bug.  git-cat-file.xml thinks it's documenting a program
called "git", with the quick description beginning with "cat-file".
Here's the relevant snippet from git-cat-file.xml:

<refnamediv>
    <refname>git</refname>
    <refpurpose>cat-file - Provide content or type information for repository objects</refpurpose>
</refnamediv>


So far it's not too bad (it's still getting the filename right, even
though the contents are less than perfect).  But when we feed that xml to
'xmlto man', xmlto sensibly uses the buggy command name "git" for the
output file name, producing "git.1".  _That_ is what we have to move.
(xmlto has no --output-filename option, or we'd just use that.)


Here's another attempt at the Makefile patch.  It's got the broken-out
man1 vs man7 layout that Jonas sensibly suggested.


Note that the asciidoc bug workaround is incredibly fragile.  If we have
any man1 pages that don't begin with "git-", it'll do the wrong thing
(because they won't be named git.1).  And if we have any man7 pages
that have "-" in the name, it'll do the wrong thing (by not renaming
the incorrectly named manpage).


Please please Stuart Rackham, Mr Asciidoc man, use David Greaves'
patch <http://marc.theaimsgroup.com/?l=git&m=111558757202243&w=2> to
fix this bug.


Index: Documentation/Makefile
===================================================================
--- a81ef956b9b2946bea2104cd11a4529c965976ad/Documentation/Makefile  (mode:100644)
+++ uncommitted/Documentation/Makefile  (mode:100644)
@@ -1,25 +1,40 @@
-DOC_SRC=$(wildcard git*.txt)
-DOC_HTML=$(patsubst %.txt,%.html,$(DOC_SRC))
-DOC_MAN=$(patsubst %.txt,%.1,$(DOC_SRC))
+MAN1_TXT=$(wildcard git-*.txt)
+MAN7_TXT=git.txt
 
-all: $(DOC_HTML) $(DOC_MAN)
+DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_TXT) $(MAN7_TXT))
+
+DOC_MAN1=$(patsubst %.txt,%.1,$(MAN1_TXT))
+DOC_MAN7=$(patsubst %.txt,%.7,$(MAN7_TXT))
+
+
+all: html man
 
 html: $(DOC_HTML)
 
-man: $(DOC_MAN)
+man: man1 man7
+
+man1: $(DOC_MAN1)
+
+man7: $(DOC_MAN7)
+
 
 # 'include' dependencies
 git-diff-%.txt: diff-format.txt
 	touch $@
 
 clean:
-	rm -f *.xml *.html *.1
+	rm -f *.xml *.html *.1 *.7
 
 %.html : %.txt
 	asciidoc -b css-embedded -d manpage $<
 
 %.1 : %.xml
 	xmlto man $<
+	@# FIXME: this next line works around an output filename bug in asciidoc 6.0.3
+	mv git.1 $@
+
+%.7 : %.xml
+	xmlto man $<
 
 %.xml : %.txt
 	asciidoc -b docbook -d manpage $<


-- 
Sebastian Kuzminsky
"Marie will know I'm headed south, so's to meet me by and by"
-Townes Van Zandt

      reply	other threads:[~2005-05-20 17:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-19 15:29 manpage name conflict Sebastian Kuzminsky
2005-05-19 15:58 ` Petr Baudis
2005-05-19 16:24   ` Sebastian Kuzminsky
2005-05-19 16:47     ` Linus Torvalds
2005-05-19 16:57     ` Linus Torvalds
2005-05-19 18:18       ` Sebastian Kuzminsky
2005-05-20 13:35         ` [PATCH] Fix and clean up man page building Jonas Fonseca
2005-05-20 14:08           ` Raja R Harinath
2005-05-20 14:52             ` Jonas Fonseca
2005-05-20 17:09               ` Sebastian Kuzminsky [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E1DZB0X-0004qW-QX@highlab.com \
    --to=seb@highlab.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.