From: Junio C Hamano <gitster@pobox•com>
To: "brian m. carlson" <sandals@crustytoothpaste•net>
Cc: git@vger•kernel.org
Subject: Re: [PATCH 3/4] Documentation: move some AsciiDoc parameters into variables
Date: Wed, 15 Oct 2014 13:43:49 -0700 [thread overview]
Message-ID: <xmqq61flvzay.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1413070656-241955-4-git-send-email-sandals@crustytoothpaste.net> (brian m. carlson's message of "Sat, 11 Oct 2014 23:37:35 +0000")
"brian m. carlson" <sandals@crustytoothpaste•net> writes:
> Asciidoctor takes slightly different arguments from AsciiDoc in some
> cases. It has a different name for the HTML backend and the "docbook"
> backend produces DocBook 5, not DocBook 4.5. Also, Asciidoctor does not
> accept the -f option. Move these values into variables so that they can
> be overridden by users wishing to use Asciidoctor instead of Asciidoc.
>
> Signed-off-by: brian m. carlson <sandals@crustytoothpaste•net>
> ---
I think it makes sense to make these customizable, but I wonder if
it makes the result easier to maintain if we make units of logical
definitions larger, e.g.
ASCIIDOC = asciidoc
TXT_TO_MANHTML = $(ASCIIDOC) -b xhtml11 -d manpage $(ASCIIDOC_CONF)
TXT_TO_ARTICLE = $(ASCIIDOC) -b docbook -d article
...
ASCIIDOC_EXTRA may want to apply all of them, even though I see that
we do not feed it to OBSOLETE_HTML right now. It may also be that
$(ASCIIDOC_CONF) and -agit_version=$(GIT_VERSION) could be shared
among the ones that currently do not have.
Then the above would become something like:
ASCIIDOC = asciidoc
ASCIIDOC_COMMON = $(ASCIIDOC) \
$(ASCIIDOC_EXTRA) $(ASCIIDOC_CONF) -agit_version=$(GIT_VERSION)
TXT_TO_MANHTML = $(ASCIIDOC_COMMON) -b xhtml11 -d manpage
...
and would further simplify this part
> $(MAN_HTML): %.html : %.txt asciidoc.conf
> $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \
> - $(ASCIIDOC) -b xhtml11 -d manpage -f asciidoc.conf \
> + $(ASCIIDOC) -b $(ASCIIDOC_HTML) -d manpage $(ASCIIDOC_CONF) \
> $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $< && \
into just
$(TXT_TO_MANHTML) -o $@+ $<
After all, our output formats are fairly limited, I would think.
Are there too many different variants and exceptions to make such an
approach infeasible?
next prev parent reply other threads:[~2014-10-15 20:43 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-11 23:37 [PATCH 0/4] Allow building Git with Asciidoctor brian m. carlson
2014-10-11 23:37 ` [PATCH 1/4] Documentation: adjust document title underlining brian m. carlson
2014-10-13 20:35 ` Junio C Hamano
2014-10-11 23:37 ` [PATCH 2/4] Documentation: fix mismatched delimiters in git-imap-send brian m. carlson
2014-10-11 23:37 ` [PATCH 3/4] Documentation: move some AsciiDoc parameters into variables brian m. carlson
2014-10-15 20:43 ` Junio C Hamano [this message]
2014-10-16 1:52 ` brian m. carlson
2014-10-11 23:37 ` [PATCH 4/4] Documentation: implement linkgit macro for Asciidoctor brian m. carlson
2014-10-13 20:41 ` [PATCH 0/4] Allow building Git with Asciidoctor Junio C Hamano
2014-10-14 0:34 ` brian m. carlson
2014-10-14 10:07 ` Jakub Narębski
2014-10-14 11:26 ` brian m. carlson
2014-10-14 9:51 ` Jeff King
2014-10-14 17:08 ` Junio C Hamano
2014-10-15 1:17 ` brian m. carlson
2014-10-15 17:43 ` Junio C Hamano
2014-10-15 11:24 ` Thomas Braun
2014-10-15 23:52 ` brian m. carlson
2014-10-16 22:53 ` Philip Oakley
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=xmqq61flvzay.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=sandals@crustytoothpaste$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox