Re: [PATCH 4/4] gdb/doc: fix parallel build of pdf and dvi files

[Andrew Burgess <aburgess@redhat.com>]

Tom Tromey <tom@tromey.com> writes:

>>>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> writes:
>
> Andrew> When building with 'make -j20 -C gdb/doc all-doc' I often see problems
> Andrew> caused from trying to build some dvi files in parallel with some pdf
> Andrew> files.  The problem files are: gdb.dvi and gdb.pdf; stabs.dvi and
> Andrew> stabs.pdf; and annotate.dvi and annotate.pdf.
>
> Andrew> The problem is that building these files create temporary files in the
> Andrew> local directory.  There's already a race here that two make threads
> Andrew> might try to create these files at the same time.
>
> Does this mean that without --build the tools here use fixed temporary
> file names?  That seems bad.

Yes, building gdb.dvi produces files matching:

  gdb.aux gdb.cp* gdb.fn* gdb.ky* gdb.log gdb.pg* gdb.toc gdb.tp* gdb.vr*

And building gdb.pdf produces the same set of files.  These two targets
use the same tool with different flags (to create dvi vs pdf).

Indeed this isn't great, which is why (I guess) the tool gained the
--build option.

The other option would be to use the same trick I used with the refcard,
copy the input file to some unique name, e.g. gdb.texi -> gdb_dvi.texi,
then the temporary files will not clash between dvi/pdf targets.

The reason I used that trick for refcard, is that is invoking
(basically) LaTeX directly, which doesn't have a --build option or
equivalent (that I could find).  For these targets (e.g. gdb.{dvi,pdf})
we're using "texi2dvi" or "texi2dvi --pdf", which does have an
"official" way to solve this problem, so I figured using that was
better.

> Anyway the patch seems ok to me.  The configure check is maybe overkill
> IMO but considering that it exists it also seems ok.

It seemed cheap to add, and there are some folk who build on older
systems.  I was worried they might not have this option.

>
> Approved-By: Tom Tromey <tom@tromey.com>

Thanks,
Andrew