Re: [PATCH] Documentation: Fix build failure of docs.

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Jul 28, 2009, 18:03 UTC
Message-ID: <4A6F3D57.2010602@drmicha.warpmail.net>
In-Reply-To: <4A6F29C5.6030608@gmail.com>

Saikiran Madugula venit, vidit, dixit 28.07.2009 18:39:

Show 37 quoted lines

> OOps, forgot to cc vger.kernel.org
> 
> Thomas Rast wrote:
>> NAK.  Presumably you are using an asciidoc 8.x?  Please check if
>> saying
>>
>>   make ASCIIDOC8=Yes man
>>
>> fixes the problem.  Read the comments in Documentation/Makefile for
>> advice on what precise combination of options you should use.  Also,
>> if you do not want to actually work on docs
>>
>>   make quick-install-man
>>
>> is a much less painful way to get manpages (in this case, from Junio's
>> 'man' branch that has preformatted manpages for 'master').
> 
> My asciidoc version is 8.4.1. Yes "make ASCIIDOC8=yes" seems to have built with
> out any problems. Thanks for quick-install-man tip, I should have read till the
> end of INSTALL document  :) .
>>
>> I put the +++ in there to stop the version I used at the time from
>> rendering the closing backtick as part of the URL and garbling the
>> entire paragraph in the process.  To be precise, with asciidoc 8.2.7
>> and without the +++ I get
>>
>>   Clone it with <tt>git clone <a href="file:///path/to/repo</tt">file:///path/to/repo</tt</a>>.
>>
>> in the HTML output.  Note the nested tags.  (With asciidoc 8.4.5 the
>> problem appears to be fixed.)
>>
> 
> People would start using latest versions of ascii doc which has no problems,
> wouldn't it be better if the default compile options suit them ? Also, it would
> be good if "make install man", would do "quick-install-man" as default to
> prevent users from the painful compilation of manpages everytime they try to
> install latest git.

"make install" does not build any documentation at all, so that should be no source of pain.

The user decides which we to go: install-man or quick-install-man.

Having the defaults set up so that recent "mainstream" versions of the tool chain work without extra options may sound like a good idea - but that would mean changing options again and again. I think we should do this for major milestones (say git 1.7).

Michael