bug-texinfo
[Top][All Lists]
Advanced

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

Re: [bug #43122] texi2dvi does not compile enough times to get toc


From: Gavin Smith
Subject: Re: [bug #43122] texi2dvi does not compile enough times to get toc
Date: Tue, 15 Sep 2015 23:25:40 +0100

On 15 September 2015 at 22:49, Vincent Belaïche
<address@hidden> wrote:
> There is another optimization that could be done: at the end of the loop
> run_bibtex and run_index are launched one more time even though that
> could be useless if the loop is broken immediately afterwards (running
> index and bibtex is useful only if we make a loop and have again a core
> conversion, otherwise it does not have any impact on the finale output).
>
> In other words we have:
>
>     run_core_conversion
>     run_bibtex
>     run_index
>     xref_files_changed || break
>
> While it should be
>
>
>     run_core_conversion
>     xref_files_changed || break
>     run_bibtex
>     run_index

I get it, the first time the aux and toc files are new, so we'll have
to rerun TeX. If TeX has to be run a third time, then it will pick up
the index files from the second round, so producing the index files on
the first round was useless. The way to change this would be to check
for changed files separately.

> However, I have tried the above, but it results in an infinite loop
> (broken after the max 7 cycles allowed). I am not yet sure why this
> happens : if I place the break condition before run_bibtex, then I get
> (with verbose -V) the following output:
>
> /local/bin/texi2dvi: Original xref files = dummy.aux
> dummy.fl
> dummy.fls
> dummy.toc
> /local/bin/texi2dvi: New xref files      = dummy.aux
> dummy.fl
> dummy.toc
>
> In other words the break condition is not met because we have dummy.fls
> in the original xref files, but not in the new xref files, so the list
> is changed which call for looping again. The reason why so is that the
> index_file_p test fails, and it fails because the .fls file is now in
> the $work_bak directory, not in the build directory. Well, this seems to
> be not only an optimization problem, but a bug...

Because the *.fls (sorted fl index file) is clobbered by the *.fls
recorder file, so it is no more. I had to change the order to get this
to work, so that the *.fls (sorted fl index file) will be created
again, after the recorder file has been renamed.



reply via email to

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