texinfo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[SPAM] Re: texinfo 5.00 -> 5.0 -> 4.13.90 html output


From: Patrice Dumas
Subject: [SPAM] Re: texinfo 5.00 -> 5.0 -> 4.13.90 html output
Date: Fri, 17 Feb 2012 01:59:21 +0100
User-agent: Mutt/1.4.2.2i

On Thu, Feb 16, 2012 at 02:48:14PM -0800, Karl Berry wrote:
> Pat,
> 
> But anyway, what I really wanted to discuss was this line:
> <!-- Created by Texinfo 5.00, http://www.gnu.org/software/texinfo/ -->
> 
> 1) it should certainly not be 5.00 since we don't number the releases
> like that.  It will be 5.0.  (I can imagine this came from CPAN-like
> module numbering, which I know is done like that, which is more logical,
> but ... too much history.)
> 
> 2) but independent of that, this seems like one of the most important
> places to use the real-life version number, namely 4.13.90.  Whether
> it's actually derived from configure.ac or not isn't critical to me, but
> I think it's important not to call it generated by 5.0 when it isn't.

I guess you called texi2any.pl?  texi2any or makeinfo have the version
from configure.ac substituted, be them in source or installed.  The 5.00 
is indeed the cpan like number.  In any case it cannot be 4.13.90 because 
texi2any.pl do not have the configure variables substituted.  So it is 
arbitrary and it happens to be higher that 4.13.90 by chance.  In the 
future it is possible that it lags behind the texinfo release number as 
there should be more texinfo releases than cpan module releases --- although 
it also depends on the version numbering schemes for texinfo and CPAN 
module respectively.

I can't see a simple way way to synchronize texi2any.pl with configure.ac 
number.  I can hardcode something else, instead of using the perl module 
version number, though.

All that being said, it seems to me that generating the texinfo manuals
(especially the Info outputs) with the cpan version number in header is
wrong, it should indeed be the configure.ac number.  One possibility could be
to use texi2any, thus with configure variables substituted and pass all
the paths to in-source libraries, like what is done in man/Makefile.am where
makeinfo is called, with all the paths set correctly. 

I attach a possible patch for doc/Makefile.am that does what I propose
above.  Would that be sufficient?

Do you have something else in mind?  If the idea is to have a command with
.pl that discovers better paths of modules in source (because it has a .pl
extension) which also have configure variables substituted, that could also 
be easily made.  Do you want that?

-- 
Pat

Attachment: Makefile.am.diff
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]