emacs-bug-tracker
[Top][All Lists]
Advanced

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

[debbugs-tracker] bug#13351: closed (Dropping support for split '.info'


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#13351: closed (Dropping support for split '.info' files in mainline Automake)
Date: Wed, 16 Jan 2013 12:49:02 +0000

Your message dated Wed, 16 Jan 2013 13:47:40 +0100
with message-id <address@hidden>
and subject line Re: bug#13351: [IMPORTANT] Dropping support for split '.info' 
files in mainline Automake
has caused the debbugs.gnu.org bug report #13351,
regarding Dropping support for split '.info' files in mainline Automake
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
13351: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13351
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: [IMPORTANT] Dropping support for split '.info' files in mainline Automake Date: Thu, 03 Jan 2013 21:53:21 +0100
Severity: wishlist

[This is posted also to the automake and texinfo lists to ensure
 a wider audience.  Discussion should continue exclusively on the
 bug-automake list, to avoid a cross-posting flood]

Automake-generated have for a long time supported "split" info files:
<http://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#Tag-and-Split-Files>

When I asked the rationale for this feature:

  <http://lists.gnu.org/archive/html/texinfo-devel/2012-08/msg00015.html>

Karl Berry confirmed that the reason for its existence was indeed
"efficiency, especially memory size":

  <http://lists.gnu.org/archive/html/texinfo-devel/2012-08/msg00024.html>

He also added that "The Elisp manual is one of the largest ones around.
Looks like it would be maybe 3.5mb as one file."  Not in any way big by
modern standards.

OTOH, it appears that the use of split info files (at least in the way
Automake-generated rules have been handling them for a long time) can
cause real problems in some (admittedly quite corner-case) situations:

  <http://thread.gmane.org/gmane.comp.parsers.bison.bugs/3963>
  <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12320>

So I believe we could follow suit with Automake-NG (see commit dd603e21,
<http://lists.gnu.org/archive/html/automake-ng/2012-08/msg00147.html>)
and have Automake-generated makefiles pass the '--no-split' option
unconditionally to makeinfo invocations (starting from Automake 1.14).
This would allow some nice simplifications in our Texinfo recipe
(exemplified by the Automake-NG patch referenced above), and offer an
automatic fix for bug#12320.

Another *very* good aspect of such a change is that it would be 100%
transparent to the Automake users.

Thoughts, opinions, objections?

Regards,
  Stefano



--- End Message ---
--- Begin Message --- Subject: Re: bug#13351: [IMPORTANT] Dropping support for split '.info' files in mainline Automake Date: Wed, 16 Jan 2013 13:47:40 +0100
On 01/12/2013 04:58 PM, Stefano Lattarini wrote:
> On 01/11/2013 10:55 PM, Paolo Bonzini wrote:
>> Il 03/01/2013 21:53, Stefano Lattarini ha scritto:
>>
>>> So I believe we could follow suit with Automake-NG (see commit dd603e21,
>>> <http://lists.gnu.org/archive/html/automake-ng/2012-08/msg00147.html>)
>>> and have Automake-generated makefiles pass the '--no-split' option
>>> unconditionally to makeinfo invocations (starting from Automake 1.14).
>>> This would allow some nice simplifications in our Texinfo recipe
>>> (exemplified by the Automake-NG patch referenced above), and offer an
>>> automatic fix for bug#12320.
>>>
>>> Another *very* good aspect of such a change is that it would be 100%
>>> transparent to the Automake users.
>>>
>>> Thoughts, opinions, objections?
>>
>> *This* is a change I support.
>>
>> Paolo
>>
> Glad to hear that.  Since so far I've received only positive feedback, I
> will proceed to push the change to master in a couple of days if nobody
> objects.
> 
Pushed now.  I'm thus closing this bug report.

Regards,
  Stefano


--- End Message ---

reply via email to

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