info files

info files

[Stephen Berman]

Recent bzr updates of the branch I use for regular builds always ended
with a conflict about info/ not being empty and therefore not deleted
(it was of course absent in my trunk mirror).  So I deleted it from the
branch manually, did `bzr resolve --all', and that eliminated the
conflict.  But now when I run make, no info files are built.  They are
built by running `make info', which creates info/ in the source
directory and populates it.  So I suppose the next time I update the
branch I'll get a conflict again and have to delete info/ manually, and
then run `make info' on the next build; and so on.  This doesn't seem
very sensible, so I guess I'm missing something, but I saw nothing in
NEWS.  So what am I missing?  In case it's relevant, I build Emacs out
of tree and do not install it.

Steve Berman

Re: info files

[Andreas Schwab]

Stephen Berman <stephen.berman@gmx.net> writes:

> So I suppose the next time I update the branch I'll get a conflict
> again

No, you won't.  It's now an ignored directory.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: info files

[Stephen Berman]

On Mon, 23 Dec 2013 18:10:53 +0100 Andreas Schwab <schwab@linux-m68k.org> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> So I suppose the next time I update the branch I'll get a conflict
>> again
>
> No, you won't.  It's now an ignored directory.

Ah, ok; thanks.  (I guess it would have been more polite to just wait
till I could update again, then I would have seen no conflict, but
thanks for indulging my impatience.)

Steve Berman

info files

[Stephen J. Turnbull]

Stephen Berman writes:

 > But now when I run make, no info files are built.

This sounds like a bug to me (I would think a plain make should update
info files).  But perhaps you need to do a bootstrap to get the info
target made?

 > They are built by running `make info', which creates info/ in the
 > source directory and populates it.  So I suppose the next time I
 > update the branch I'll get a conflict again

Nope, as Andreas explained, you won't ever notice this again.

You can trust Bazaar to get this right.  In fact, ignoring the
directory is simply a convenience to prevent bzr from nagging you
about the "new" object created by Make (just like it's a convenience
for any build product).

If you have an existing branch old enough to still have the info
directory that you want to merge, no problem as long as the info
directory contains no unmerged changes.  bzr will merge the delete
operation for you.  Only if you have an old branch that contains
changes to the info directory that never made it to trunk will you get
a conflict.  But this is a "real" conflict that you need to resolve.

Re: info files

[Paul Eggert]

Stephen J. Turnbull wrote:
> Stephen Berman writes:
> 
>  > But now when I run make, no info files are built.
> 
> This sounds like a bug to me (I would think a plain make should update
> info files).

The GNU coding standards says that 'make all' need not
rebuild documentation files, and that 'make info'
should build them.

Re: info files

[Stephen J. Turnbull]

Paul Eggert writes:

 > The GNU coding standards says that 'make all' need not
 > rebuild documentation files,

Then the coding standards are buggy! ;-)

Seriously, having "make" rebuild docs doesn't *violate* the standard,
does it?  AFAICS, it would be a one-time annoyance per existing
checkout: the first time you rebuild after the commit of "bzr rm
info", it would take a noticable amount of time.  But surely it's
hardly noticable in a "make bootstrap", and in any other situation
.texi files change far less frequently than C or Lisp source, and
rebuild quickly (except maybe the Lispref).

Re: info files

[Paul Eggert]

Stephen J. Turnbull wrote:
> having "make" rebuild docs doesn't *violate* the standard,
> does it?

True.

> AFAICS, it would be a one-time annoyance per existing
> checkout: the first time you rebuild after the commit of "bzr rm
> info", it would take a noticable amount of time.  But surely it's
> hardly noticable in a "make bootstrap".

It takes quite some time even compared to a "make bootstrap",
I'm afraid.  On my platform (AMD Phenom II X4 910e, texinfo 5.2),
a fresh "make info" takes 3 minutes 19 seconds.  It can be parallelized with "make -j",
but some developers are still using older single-core machines,
considerably slower than what I use.

Plus, one doesn't need to run "make bootstrap" from a fresh checkout.

Re: info files

[Eli Zaretskii]

> Date: Tue, 24 Dec 2013 10:02:22 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: emacs-devel@gnu.org
> 
> On my platform (AMD Phenom II X4 910e, texinfo 5.2), a fresh "make
> info" takes 3 minutes 19 seconds.      ^^^^^^^^^^^

Downgrade to makeinfo 4.x, and it becomes a snap, especially with -j.

Re: info files

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Downgrade to makeinfo 4.x, and it becomes a snap, especially with -j.

Oh, so that's what it is.  I was building Gnus on this laptop and
thought something had crashed while making the Gnus manual, so I started
stracing and stuff to debug, but it eventually finished.

How did they manage to make makeinfo so much slower?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: info files

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> How did they manage to make makeinfo so much slower?

Oh, they rewrote it in Perl.  :-/

I compared building a smaller manual with Emacs compared to makeinfo:

[larsi@building texi]$ time emacs -batch -q -no-site-file -l ./infohack.el -f batch-makeinfo emacs-mime.texi 
real	0m1.567s
user	0m1.383s
sys	0m0.141s
[larsi@building texi]$ time makeinfo emacs-mime.texi 

real	0m2.885s
user	0m2.792s
sys	0m0.058s

So Emacs is now 2x faster than makeinfo.  But it seems to lack some
functionality:

@indicateurl is not handled by texinfo

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: info files

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: stephen@xemacs.org,  Paul Eggert <eggert@cs.ucla.edu>,  emacs-devel@gnu.org
> Date: Tue, 24 Dec 2013 19:37:56 +0100
> MailScanner-NULL-Check: 1388515433.76651@deLOJqbOnIz9iaAfMWfJWw
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > How did they manage to make makeinfo so much slower?
> 
> Oh, they rewrote it in Perl.  :-/

Yep.  As result, makeinfo is about 20 times slower now.

> So Emacs is now 2x faster than makeinfo.  But it seems to lack some
> functionality:
> 
> @indicateurl is not handled by texinfo

texinfmt.el has not been updated with the latest Texinfo features for
a long time, because makeinfo is readily available.

Re: info files

[Stefan Monnier]

> It takes quite some time even compared to a "make bootstrap",
> I'm afraid.  On my platform (AMD Phenom II X4 910e, texinfo 5.2),

AFAIK the recent change made no difference in this respect: the Info
files were not under version control.  The only difference is that the
info/dir file is now rebuilt, which takes very little time,


        Stefan