* info files
@ 2013-12-23 16:07 Stephen Berman
2013-12-23 17:10 ` Andreas Schwab
2013-12-24 2:30 ` Stephen J. Turnbull
0 siblings, 2 replies; 12+ messages in thread
From: Stephen Berman @ 2013-12-23 16:07 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: info files
2013-12-23 16:07 info files Stephen Berman
@ 2013-12-23 17:10 ` Andreas Schwab
2013-12-23 17:17 ` Stephen Berman
2013-12-24 2:30 ` Stephen J. Turnbull
1 sibling, 1 reply; 12+ messages in thread
From: Andreas Schwab @ 2013-12-23 17:10 UTC (permalink / raw
To: Stephen Berman; +Cc: emacs-devel
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."
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: info files
2013-12-23 17:10 ` Andreas Schwab
@ 2013-12-23 17:17 ` Stephen Berman
0 siblings, 0 replies; 12+ messages in thread
From: Stephen Berman @ 2013-12-23 17:17 UTC (permalink / raw
To: Andreas Schwab; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* info files
2013-12-23 16:07 info files Stephen Berman
2013-12-23 17:10 ` Andreas Schwab
@ 2013-12-24 2:30 ` Stephen J. Turnbull
2013-12-24 5:50 ` Paul Eggert
1 sibling, 1 reply; 12+ messages in thread
From: Stephen J. Turnbull @ 2013-12-24 2:30 UTC (permalink / raw
To: Stephen Berman; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: info files
2013-12-24 2:30 ` Stephen J. Turnbull
@ 2013-12-24 5:50 ` Paul Eggert
2013-12-24 6:32 ` Stephen J. Turnbull
0 siblings, 1 reply; 12+ messages in thread
From: Paul Eggert @ 2013-12-24 5:50 UTC (permalink / raw
To: Stephen J. Turnbull; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: info files
2013-12-24 5:50 ` Paul Eggert
@ 2013-12-24 6:32 ` Stephen J. Turnbull
2013-12-24 18:02 ` Paul Eggert
0 siblings, 1 reply; 12+ messages in thread
From: Stephen J. Turnbull @ 2013-12-24 6:32 UTC (permalink / raw
To: Paul Eggert; +Cc: emacs-devel
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).
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: info files
2013-12-24 6:32 ` Stephen J. Turnbull
@ 2013-12-24 18:02 ` Paul Eggert
2013-12-24 18:14 ` Eli Zaretskii
2013-12-24 19:28 ` Stefan Monnier
0 siblings, 2 replies; 12+ messages in thread
From: Paul Eggert @ 2013-12-24 18:02 UTC (permalink / raw
To: Stephen J. Turnbull; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: info files
2013-12-24 18:02 ` Paul Eggert
@ 2013-12-24 18:14 ` Eli Zaretskii
2013-12-24 18:27 ` Lars Ingebrigtsen
2013-12-24 19:28 ` Stefan Monnier
1 sibling, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2013-12-24 18:14 UTC (permalink / raw
To: Paul Eggert; +Cc: stephen, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: info files
2013-12-24 18:14 ` Eli Zaretskii
@ 2013-12-24 18:27 ` Lars Ingebrigtsen
2013-12-24 18:37 ` Lars Ingebrigtsen
0 siblings, 1 reply; 12+ messages in thread
From: Lars Ingebrigtsen @ 2013-12-24 18:27 UTC (permalink / raw
To: Eli Zaretskii; +Cc: stephen, Paul Eggert, emacs-devel
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/
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: info files
2013-12-24 18:27 ` Lars Ingebrigtsen
@ 2013-12-24 18:37 ` Lars Ingebrigtsen
2013-12-24 18:52 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Lars Ingebrigtsen @ 2013-12-24 18:37 UTC (permalink / raw
To: Eli Zaretskii; +Cc: stephen, Paul Eggert, emacs-devel
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/
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: info files
2013-12-24 18:37 ` Lars Ingebrigtsen
@ 2013-12-24 18:52 ` Eli Zaretskii
0 siblings, 0 replies; 12+ messages in thread
From: Eli Zaretskii @ 2013-12-24 18:52 UTC (permalink / raw
To: Lars Ingebrigtsen; +Cc: stephen, eggert, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: info files
2013-12-24 18:02 ` Paul Eggert
2013-12-24 18:14 ` Eli Zaretskii
@ 2013-12-24 19:28 ` Stefan Monnier
1 sibling, 0 replies; 12+ messages in thread
From: Stefan Monnier @ 2013-12-24 19:28 UTC (permalink / raw
To: Paul Eggert; +Cc: Stephen J. Turnbull, emacs-devel
> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2013-12-24 19:28 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-12-23 16:07 info files Stephen Berman
2013-12-23 17:10 ` Andreas Schwab
2013-12-23 17:17 ` Stephen Berman
2013-12-24 2:30 ` Stephen J. Turnbull
2013-12-24 5:50 ` Paul Eggert
2013-12-24 6:32 ` Stephen J. Turnbull
2013-12-24 18:02 ` Paul Eggert
2013-12-24 18:14 ` Eli Zaretskii
2013-12-24 18:27 ` Lars Ingebrigtsen
2013-12-24 18:37 ` Lars Ingebrigtsen
2013-12-24 18:52 ` Eli Zaretskii
2013-12-24 19:28 ` Stefan Monnier
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).