* [PATCH 0/4] gdb/doc: build fixes and improvements @ 2024-05-11 9:37 Andrew Burgess 2024-05-11 9:37 ` [PATCH 1/4] gdb/doc: don't delete *.pod files too early Andrew Burgess ` (4 more replies) 0 siblings, 5 replies; 42+ messages in thread From: Andrew Burgess @ 2024-05-11 9:37 UTC (permalink / raw) To: gdb-patches; +Cc: Andrew Burgess The first patch in this series is a minor bug fix for my recent doc/Makefile.in patch -- it's not serious, we end up rebuilding some things unnecessarily, but everything does build correctly. The second patch removes some dead code from the Makefile.in. The third and fourth patches fix some build issues when trying to build all the docs in parallel. Normally, when building gdb we only build the info pages from the docs/ directory, and this works fine in parallel. But if you try 'make -j20 -C gdb/doc all-docs' you'll find there are some issues with recipes not working when run in parallel. These should all be fixed with this series. -- Andrew Burgess (4): gdb/doc: don't delete *.pod files too early gdb/doc: don't try to copy GDBvn.texi from the source tree gdb/doc: fix parallel build of refcard related targets gdb/doc: fix parallel build of pdf and dvi files gdb/configure | 33 +++++++++++++- gdb/configure.ac | 21 +++++++++ gdb/doc/Makefile.in | 104 ++++++++++++++++++++++---------------------- 3 files changed, 103 insertions(+), 55 deletions(-) base-commit: a4f76c0765a0b9c643dc91d5a398a1cd9519572b -- 2.25.4 ^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 1/4] gdb/doc: don't delete *.pod files too early 2024-05-11 9:37 [PATCH 0/4] gdb/doc: build fixes and improvements Andrew Burgess @ 2024-05-11 9:37 ` Andrew Burgess 2024-05-13 16:13 ` Tom Tromey 2024-05-11 9:37 ` [PATCH 2/4] gdb/doc: don't try to copy GDBvn.texi from the source tree Andrew Burgess ` (3 subsequent siblings) 4 siblings, 1 reply; 42+ messages in thread From: Andrew Burgess @ 2024-05-11 9:37 UTC (permalink / raw) To: gdb-patches; +Cc: Andrew Burgess When doing 'make -C gdb/doc man' to build the man pages, I noticed that the outputs were being rebuilt each time the make command was rerun, even when the input files hadn't changed. This was caused by this commit: commit 824083f34c222aa7419e2ea58e82d6f230d5f531 Date: Fri Apr 12 17:47:20 2024 +0100 gdb/doc: use silent-rules.mk in the Makefile Which split the generation of the .pod file from the actual creation of the man page file. Prior to this split it was OK to delete the .pod file at the end of the recipe, the rule depending on the .texi input file, and output was the .1 or .5 man page file. Now however, with the split, the man page creation depends on the .pod file, if we delete this after creating the .1 or .5 man page file then the next time we run 'make' the .pod file is missing and is regenerated, which in turn triggers the regeneration of the man page file. Fix this by leaving the .pod file around, and only cleaning up these files in the 'mostlyclean' target. Which leads to a second problem, the POD_FILE_TMPS is not created correctly, so we don't actually clean up the .pod files! This too is fixed in this commit. After this commit running 'make -C gdb/doc man' will build the manual pages the first time, and each subsequent run will do nothing. Running 'make -C gdb/doc mostlyclean' will now delete the .pod files. --- gdb/doc/Makefile.in | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/gdb/doc/Makefile.in b/gdb/doc/Makefile.in index 28d829fdfee..3f3fe7b7ed9 100644 --- a/gdb/doc/Makefile.in +++ b/gdb/doc/Makefile.in @@ -190,8 +190,8 @@ MANS = $(MAN1S) $(MAN5S) # The pod files that are generated as a side effect of creating the # man pages. -POD_FILE_TMPS = $(patsubst %.1,%.pod,$MAN1S) \ - $(patsubst %.5,%.pod,$MAN1S) +POD_FILE_TMPS = $(patsubst %.1,%.pod,$(MAN1S)) \ + $(patsubst %.5,%.pod,$(MAN5S)) HAVE_NATIVE_GCORE_TARGET = @HAVE_NATIVE_GCORE_TARGET@ HAVE_NATIVE_GCORE_HOST = @HAVE_NATIVE_GCORE_HOST@ @@ -665,12 +665,10 @@ annotate/index.html: $(ANNOTATE_DOC_FILES) $(MAN1S) : %.1 : %.pod $(GDB_DOC_FILES) $(ECHO_TEXI2MAN) ($(POD2MAN1) $*.pod | sed -e '/^.if n .na/d' > $@.T$$$$ && \ mv -f $@.T$$$$ $@) || (rm -f $@.T$$$$ && exit 1) - $(SILENCE) rm -f $*.pod $(MAN5S) : %.5 : %.pod $(GDB_DOC_FILES) $(ECHO_TEXI2MAN) ($(POD2MAN1) $*.pod | sed -e '/^.if n .na/d' > $@.T$$$$ && \ mv -f $@.T$$$$ $@) || (rm -f $@.T$$$$ && exit 1) - $(SILENCE) rm -f $*.pod force: -- 2.25.4 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 1/4] gdb/doc: don't delete *.pod files too early 2024-05-11 9:37 ` [PATCH 1/4] gdb/doc: don't delete *.pod files too early Andrew Burgess @ 2024-05-13 16:13 ` Tom Tromey 2024-05-14 15:53 ` Andrew Burgess 0 siblings, 1 reply; 42+ messages in thread From: Tom Tromey @ 2024-05-13 16:13 UTC (permalink / raw) To: Andrew Burgess; +Cc: gdb-patches >>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> writes: Andrew> After this commit running 'make -C gdb/doc man' will build the manual Andrew> pages the first time, and each subsequent run will do nothing. Andrew> Running 'make -C gdb/doc mostlyclean' will now delete the .pod files. This looks good to me. Approved-By: Tom Tromey <tom@tromey.com> Tom ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 1/4] gdb/doc: don't delete *.pod files too early 2024-05-13 16:13 ` Tom Tromey @ 2024-05-14 15:53 ` Andrew Burgess 0 siblings, 0 replies; 42+ messages in thread From: Andrew Burgess @ 2024-05-14 15:53 UTC (permalink / raw) To: Tom Tromey; +Cc: gdb-patches Tom Tromey <tom@tromey.com> writes: >>>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> writes: > > Andrew> After this commit running 'make -C gdb/doc man' will build the manual > Andrew> pages the first time, and each subsequent run will do nothing. > > Andrew> Running 'make -C gdb/doc mostlyclean' will now delete the .pod files. > > This looks good to me. > Approved-By: Tom Tromey <tom@tromey.com> Pushed. Thanks, Andrew ^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 2/4] gdb/doc: don't try to copy GDBvn.texi from the source tree 2024-05-11 9:37 [PATCH 0/4] gdb/doc: build fixes and improvements Andrew Burgess 2024-05-11 9:37 ` [PATCH 1/4] gdb/doc: don't delete *.pod files too early Andrew Burgess @ 2024-05-11 9:37 ` Andrew Burgess 2024-05-13 16:12 ` Tom Tromey 2024-05-11 9:37 ` [PATCH 3/4] gdb/doc: fix parallel build of refcard related targets Andrew Burgess ` (2 subsequent siblings) 4 siblings, 1 reply; 42+ messages in thread From: Andrew Burgess @ 2024-05-11 9:37 UTC (permalink / raw) To: gdb-patches; +Cc: Andrew Burgess Long ago we used to carry a copy of GDBvn.texi in the source tree. The build recipe for gdb.dvi and gdb.pdf contained instructions for copying this file from the source tree if the file had not been generated. That's right, we also have a rule that builds GDBvn.texi, and GDBvn.texi is in the dependency list for both gdb.dvi and gdb.pdf. On top of this, GDBvn.texi was removed from the source tree in 2000, in this commit: commit 1171f8d754f71e35fd2f6c4e82b00f3c685e515f Date: Tue Feb 8 03:37:34 2000 +0000 2000-02-07 Jason Molenda (jsm@bugshack.cygnus.com) I think we can assume that everyone is happy generating GDBvn.texi, so lets remove the redundant copying code. --- gdb/doc/Makefile.in | 17 ----------------- 1 file changed, 17 deletions(-) diff --git a/gdb/doc/Makefile.in b/gdb/doc/Makefile.in index 3f3fe7b7ed9..9e3ce018e86 100644 --- a/gdb/doc/Makefile.in +++ b/gdb/doc/Makefile.in @@ -477,15 +477,6 @@ gdb-cfg.texi: ${srcdir}/${DOC_CONFIG}-cfg.texi ln ${srcdir}/${DOC_CONFIG}-cfg.texi gdb-cfg.texi || \ cp ${srcdir}/${DOC_CONFIG}-cfg.texi gdb-cfg.texi -# GDB MANUAL: texinfo source, using @set/@clear/@value/@ifset/@ifclear -# If your texinfo or makeinfo don't support these, get a new texinfo release -# -# The nonsense with GDBvn.texi gets this to run with both Sun and GNU make. -# Note that we can *generate* GDBvn.texi, but since we distribute one in the -# source directory for the benefit of people who *don't* use this makefile, -# VPATH will often tell make not to bother building it, because the one -# in the srcdir is up to date. (if not, then make should build one here). - # Clean these up before each run. Avoids a catch 22 with not being # able to re-generate these files (to fix a corruption) because these # files contain a corruption. @@ -494,10 +485,6 @@ GDB_TEX_TMPS = gdb.aux gdb.cp* gdb.fn* gdb.ky* gdb.log gdb.pg* gdb.toc \ # GDB MANUAL: TeX dvi file gdb.dvi: ${GDB_DOC_FILES} - $(SILENCE) if [ ! -f ./GDBvn.texi ]; then \ - (test "$(LN_S)" = "ln -s" && ln -s $(srcdir)/GDBvn.texi .) || \ - ln $(srcdir)/GDBvn.texi . || \ - cp $(srcdir)/GDBvn.texi . ; else true; fi $(SILENCE) rm -f $(GDB_TEX_TMPS) $(ECHO_TEXI2DVI) $(TEXI2DVI) $(SILENT_Q_FLAG) $(READLINE_TEXI_INCFLAG) \ -I ${GDBMI_DIR} -I $(srcdir) $(srcdir)/gdb.texinfo @@ -506,10 +493,6 @@ gdb.ps: gdb.dvi $(ECHO_DVIPS) $(DVIPS) $(SILENT_Q_FLAG) -o $@ $? gdb.pdf: ${GDB_DOC_FILES} - $(SILENCE) if [ ! -f ./GDBvn.texi ]; then \ - (test "$(LN_S)" = "ln -s" && ln -s $(srcdir)/GDBvn.texi .) || \ - ln $(srcdir)/GDBvn.texi . || \ - cp $(srcdir)/GDBvn.texi . ; else true; fi $(SILENCE) rm -f $(GDB_TEX_TMPS) $(ECHO_TEXI2DVI) $(TEXI2DVI) $(SILENT_Q_FLAG) --pdf \ $(READLINE_TEXI_INCFLAG) -I ${GDBMI_DIR} -I $(srcdir) \ -- 2.25.4 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 2/4] gdb/doc: don't try to copy GDBvn.texi from the source tree 2024-05-11 9:37 ` [PATCH 2/4] gdb/doc: don't try to copy GDBvn.texi from the source tree Andrew Burgess @ 2024-05-13 16:12 ` Tom Tromey 2024-05-13 17:33 ` Eli Zaretskii 2024-06-14 19:06 ` Pedro Alves 0 siblings, 2 replies; 42+ messages in thread From: Tom Tromey @ 2024-05-13 16:12 UTC (permalink / raw) To: Andrew Burgess; +Cc: gdb-patches >>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> writes: Andrew> That's right, we also have a rule that builds GDBvn.texi, and Andrew> GDBvn.texi is in the dependency list for both gdb.dvi and gdb.pdf. Andrew> On top of this, GDBvn.texi was removed from the source tree in 2000, Andrew> in this commit: Andrew> commit 1171f8d754f71e35fd2f6c4e82b00f3c685e515f Andrew> Date: Tue Feb 8 03:37:34 2000 +0000 Andrew> 2000-02-07 Jason Molenda (jsm@bugshack.cygnus.com) Andrew> I think we can assume that everyone is happy generating GDBvn.texi, so Andrew> lets remove the redundant copying code. I am not sure about this change. I downloaded gdb-14.2.tar.xz and I do see gdb/doc/GDBvn.texi in the source tree there. I think this is done because we also ship the .info files, so that users won't have to have makeinfo in order to build. (I'm not sure how well that plan really works since there used to be open bugs about not building when makeinfo is missing ... not sure of the current state.) Tom ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 2/4] gdb/doc: don't try to copy GDBvn.texi from the source tree 2024-05-13 16:12 ` Tom Tromey @ 2024-05-13 17:33 ` Eli Zaretskii 2024-05-14 13:32 ` Andrew Burgess 2024-06-14 19:06 ` Pedro Alves 1 sibling, 1 reply; 42+ messages in thread From: Eli Zaretskii @ 2024-05-13 17:33 UTC (permalink / raw) To: Tom Tromey; +Cc: aburgess, gdb-patches > From: Tom Tromey <tom@tromey.com> > Cc: gdb-patches@sourceware.org > Date: Mon, 13 May 2024 10:12:35 -0600 > > >>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> writes: > > Andrew> That's right, we also have a rule that builds GDBvn.texi, and > Andrew> GDBvn.texi is in the dependency list for both gdb.dvi and gdb.pdf. > > Andrew> On top of this, GDBvn.texi was removed from the source tree in 2000, > Andrew> in this commit: > > Andrew> commit 1171f8d754f71e35fd2f6c4e82b00f3c685e515f > Andrew> Date: Tue Feb 8 03:37:34 2000 +0000 > > Andrew> 2000-02-07 Jason Molenda (jsm@bugshack.cygnus.com) > > Andrew> I think we can assume that everyone is happy generating GDBvn.texi, so > Andrew> lets remove the redundant copying code. > > I am not sure about this change. > > I downloaded gdb-14.2.tar.xz and I do see gdb/doc/GDBvn.texi in the > source tree there. I think this is done because we also ship the .info > files, so that users won't have to have makeinfo in order to build. Right. So I don't think we should remove GDBvn.texi from the tarball. > (I'm not sure how well that plan really works since there used to be > open bugs about not building when makeinfo is missing ... not sure of > the current state.) Building GDB doesn't require running makeinfo, at least it didn't in GDB 14. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 2/4] gdb/doc: don't try to copy GDBvn.texi from the source tree 2024-05-13 17:33 ` Eli Zaretskii @ 2024-05-14 13:32 ` Andrew Burgess 0 siblings, 0 replies; 42+ messages in thread From: Andrew Burgess @ 2024-05-14 13:32 UTC (permalink / raw) To: Eli Zaretskii, Tom Tromey; +Cc: gdb-patches Eli Zaretskii <eliz@gnu.org> writes: >> From: Tom Tromey <tom@tromey.com> >> Cc: gdb-patches@sourceware.org >> Date: Mon, 13 May 2024 10:12:35 -0600 >> >> >>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> writes: >> >> Andrew> That's right, we also have a rule that builds GDBvn.texi, and >> Andrew> GDBvn.texi is in the dependency list for both gdb.dvi and gdb.pdf. >> >> Andrew> On top of this, GDBvn.texi was removed from the source tree in 2000, >> Andrew> in this commit: >> >> Andrew> commit 1171f8d754f71e35fd2f6c4e82b00f3c685e515f >> Andrew> Date: Tue Feb 8 03:37:34 2000 +0000 >> >> Andrew> 2000-02-07 Jason Molenda (jsm@bugshack.cygnus.com) >> >> Andrew> I think we can assume that everyone is happy generating GDBvn.texi, so >> Andrew> lets remove the redundant copying code. >> >> I am not sure about this change. >> >> I downloaded gdb-14.2.tar.xz and I do see gdb/doc/GDBvn.texi in the >> source tree there. I think this is done because we also ship the .info >> files, so that users won't have to have makeinfo in order to build. > > Right. So I don't think we should remove GDBvn.texi from the tarball. OK, I'll drop this patch. I'll likely post the inverse patch at some point -- we have other recipes that use GDBvn.texi, but don't include the copy code, so maybe they should? I'll take another look, including trying with a release tar ball, maybe there's a reason why some rules that depend on GDBvn.texi, while others don't.... but that can all wait for some future patch. > >> (I'm not sure how well that plan really works since there used to be >> open bugs about not building when makeinfo is missing ... not sure of >> the current state.) > > Building GDB doesn't require running makeinfo, at least it didn't in > GDB 14. I'll double check the status of this after these changes. Thanks, Andrew ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 2/4] gdb/doc: don't try to copy GDBvn.texi from the source tree 2024-05-13 16:12 ` Tom Tromey 2024-05-13 17:33 ` Eli Zaretskii @ 2024-06-14 19:06 ` Pedro Alves 1 sibling, 0 replies; 42+ messages in thread From: Pedro Alves @ 2024-06-14 19:06 UTC (permalink / raw) To: Tom Tromey, Andrew Burgess; +Cc: gdb-patches On 2024-05-13 17:12, Tom Tromey wrote: >>>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> writes: > > Andrew> That's right, we also have a rule that builds GDBvn.texi, and > Andrew> GDBvn.texi is in the dependency list for both gdb.dvi and gdb.pdf. > > Andrew> On top of this, GDBvn.texi was removed from the source tree in 2000, > Andrew> in this commit: > > Andrew> commit 1171f8d754f71e35fd2f6c4e82b00f3c685e515f > Andrew> Date: Tue Feb 8 03:37:34 2000 +0000 > > Andrew> 2000-02-07 Jason Molenda (jsm@bugshack.cygnus.com) > > Andrew> I think we can assume that everyone is happy generating GDBvn.texi, so > Andrew> lets remove the redundant copying code. > > I am not sure about this change. > > I downloaded gdb-14.2.tar.xz and I do see gdb/doc/GDBvn.texi in the > source tree there. I think this is done because we also ship the .info > files, so that users won't have to have makeinfo in order to build. > > (I'm not sure how well that plan really works since there used to be > open bugs about not building when makeinfo is missing ... not sure of > the current state.) Sometimes filesystem timestamps will end up messed up and building a release will want to rebuild the docs. But you can always work around that with "make MAKEINFO=true". ^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 3/4] gdb/doc: fix parallel build of refcard related targets 2024-05-11 9:37 [PATCH 0/4] gdb/doc: build fixes and improvements Andrew Burgess 2024-05-11 9:37 ` [PATCH 1/4] gdb/doc: don't delete *.pod files too early Andrew Burgess 2024-05-11 9:37 ` [PATCH 2/4] gdb/doc: don't try to copy GDBvn.texi from the source tree Andrew Burgess @ 2024-05-11 9:37 ` Andrew Burgess 2024-05-13 16:13 ` Tom Tromey 2024-05-11 9:37 ` [PATCH 4/4] gdb/doc: fix parallel build of pdf and dvi files Andrew Burgess 2024-05-31 8:18 ` [PATCHv2 0/5] gdb/doc: parallel build fixes and improvements Andrew Burgess 4 siblings, 1 reply; 42+ messages in thread From: Andrew Burgess @ 2024-05-11 9:37 UTC (permalink / raw) To: gdb-patches; +Cc: Andrew Burgess There are two problems we encounter when trying to build the refcard related target in parallel, i.e.: $ make -j20 -C gdb/doc/ refcard.dvi refcard.ps refcard.pdf These problems are: (1) The refcard.dvi and refcard.pdf targets both try and generate the tmp.sed and sedref.tex files. If two make threads end up trying to create these files at the same time then the result is these files become corrupted. I've fixed this by creating a new rule that creates sedref.tex, both refcard.dvi and refcard.pdf now depend on this, and make will build sedref.tex just once. The tmp.sed file is now generated as refcard.sed, this is generated and deleted as a temporary file within the sedref.tex recipe. (2) Having created sedref.tex the recipes for refcard.dvi and refcard.pdf both run various LaTeX based tools with sedref.tex as the input file. The problem with this is that these tools all rely on creating temporary files calls sedref.*. If the refcard.dvi and refcard.pdf rules run at the same time then these temporary files clash and overwrite each other causing the build to fail. We already copy the result file in order to rename it, our input file is sedref.tex which results in an output file named sedref.dvi or sedref.pdf, but we actually want refcard.dvi or refcard.pdf. So within the recipe for refcard.dvi I copy the input file from sedref.tex to sedref_dvi.tex. Now all the temp files are named sedref_dvi.* and the output is sedref_dvi.dvi, I then rename this new output file to refcard.dvi. I've done the same thing for refcard.pdf, but I copy the input to sedref_pdf.tex. In this way the temp files no longer clash, and both recipes can safely run in parallel. After this commit I was able to reliably build all of the refcard targets in parallel. There should be no change in the final file. --- gdb/doc/Makefile.in | 39 ++++++++++++++++++++------------------- 1 file changed, 20 insertions(+), 19 deletions(-) diff --git a/gdb/doc/Makefile.in b/gdb/doc/Makefile.in index 9e3ce018e86..c05e561edeb 100644 --- a/gdb/doc/Makefile.in +++ b/gdb/doc/Makefile.in @@ -410,31 +410,32 @@ de-stage3: force -(cd stage3 ; mv -f * ..) -rmdir stage3 -# GDB QUICK REFERENCE (dvi output) -refcard.dvi : refcard.tex $(REFEDITS) - $(SILENCE) echo > tmp.sed + +sedref.tex : refcard.tex $(REFEDITS) + $(SILENCE) echo > refcard.sed $(SILENCE) for f in x $(REFEDITS) ; do \ test x$$f = xx && continue ; \ - cat $(srcdir)/$$f >>tmp.sed ; \ + cat $(srcdir)/$$f >>refcard.sed ; \ done - $(SILENCE) sed -f tmp.sed $(srcdir)/refcard.tex >sedref.tex - $(ECHO_TEX) $(SET_TEXINPUTS) $(TEX) sedref.tex - $(SILENCE) mv sedref.dvi refcard.dvi - $(SILENCE) rm -f sedref.log sedref.tex tmp.sed + $(ECHO_GEN) sed -f refcard.sed $(srcdir)/refcard.tex >$@ + $(SILENCE) rm -f refcard.sed + + +# GDB QUICK REFERENCE (dvi output) +refcard.dvi : sedref.tex + $(SILENCE) rm -f sedref_dvi.* + $(SILENCE) cp $< sedref_dvi.tex + $(ECHO_TEX) $(SET_TEXINPUTS) $(TEX) sedref_dvi.tex && \ + mv sedref_dvi.dvi $@ refcard.ps : refcard.dvi $(ECHO_DVIPS) $(DVIPS) $(SILENT_Q_FLAG) -t landscape -o $@ $? -refcard.pdf : refcard.tex $(REFEDITS) - $(SILENCE) echo > tmp.sed - $(SILENCE) for f in x $(REFEDITS) ; do \ - test x$$f = xx && continue ; \ - cat $(srcdir)/$$f >>tmp.sed ; \ - done - $(SILENCE) sed -f tmp.sed $(srcdir)/refcard.tex >sedref.tex - $(ECHO_PDFTEX) $(SET_TEXINPUTS) $(PDFTEX) sedref.tex - $(SILENCE) mv sedref.pdf refcard.pdf - $(SILENCE) rm -f sedref.log sedref.tex tmp.sed +refcard.pdf : sedref.tex + $(SILENCE) rm -f sedref_pdf.* + $(SILENCE) cp $< sedref_pdf.tex + $(ECHO_PDFTEX) $(SET_TEXINPUTS) $(PDFTEX) sedref_pdf.tex && \ + mv sedref_pdf.pdf $@ # File to record current GDB version number. GDBvn.texi : version.subst @@ -667,7 +668,7 @@ mostlyclean: rm -f $(GDB_TEX_TMPS) rm -f $(STABS_TEX_TMPS) rm -f $(ANNOTATE_TEX_TMPS) - rm -f sedref.dvi sedref.tex tmp.sed sedref.log + rm -f refcard.sed sedref.tex sedref_dvi.* sedref_pdf.* rm -f $(POD_FILE_TMPS) clean: mostlyclean -- 2.25.4 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 3/4] gdb/doc: fix parallel build of refcard related targets 2024-05-11 9:37 ` [PATCH 3/4] gdb/doc: fix parallel build of refcard related targets Andrew Burgess @ 2024-05-13 16:13 ` Tom Tromey 0 siblings, 0 replies; 42+ messages in thread From: Tom Tromey @ 2024-05-13 16:13 UTC (permalink / raw) To: Andrew Burgess; +Cc: gdb-patches >>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> writes: Andrew> After this commit I was able to reliably build all of the refcard Andrew> targets in parallel. There should be no change in the final file. Looks good, thank you. Approved-By: Tom Tromey <tom@tromey.com> Tom ^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 4/4] gdb/doc: fix parallel build of pdf and dvi files 2024-05-11 9:37 [PATCH 0/4] gdb/doc: build fixes and improvements Andrew Burgess ` (2 preceding siblings ...) 2024-05-11 9:37 ` [PATCH 3/4] gdb/doc: fix parallel build of refcard related targets Andrew Burgess @ 2024-05-11 9:37 ` Andrew Burgess 2024-05-13 16:18 ` Tom Tromey 2024-05-31 8:18 ` [PATCHv2 0/5] gdb/doc: parallel build fixes and improvements Andrew Burgess 4 siblings, 1 reply; 42+ messages in thread From: Andrew Burgess @ 2024-05-11 9:37 UTC (permalink / raw) To: gdb-patches; +Cc: Andrew Burgess When building with 'make -j20 -C gdb/doc all-doc' I often see problems caused from trying to build some dvi files in parallel with some pdf files. The problem files are: gdb.dvi and gdb.pdf; stabs.dvi and stabs.pdf; and annotate.dvi and annotate.pdf. The problem is that building these files create temporary files in the local directory. There's already a race here that two make threads might try to create these files at the same time. But it gets worse, to avoid issues where a failed build could leave these temporary files in a corrupted state, and so prevent the next build from succeeding, the recipe for each of these files delete all the temporary files first, this obviously causes problems if some other thread has already started the build and is relying on these temporary files. To work around this problem I propose we start using the --build flag for texi2dvi (which is the same tool used to create the pdf files). The --build flag allows for the temporary files to be placed into a sub-directory, e.g. creating gdb.pdf will create the temporary files in gdb.t2d/pdf/ and gdb.dvi uses gdb.t2d/dvi/, in this way the temporary files will never clash, and we can easily delete the specific sub-directory at the start of the recipe to ensure a successful build. Very old versions of texi2dvi don't support --build, so I've added a configure check for this option. If the option is not supported then we don't use it. This means we fall back to placing temporary files in the local directory, which means parallel builds will remain broken. The --build option is definitely present in texi2dvi version 6.1, from 2016, so any version after that should be fine. For me, with this fix in place, I can now run 'make -j20 -C gdb/doc all-doc' without seeing any build problems. --- gdb/configure | 33 +++++++++++++++++++++++++++++++-- gdb/configure.ac | 21 +++++++++++++++++++++ gdb/doc/Makefile.in | 42 +++++++++++++++++++++++++++++------------- 3 files changed, 81 insertions(+), 15 deletions(-) diff --git a/gdb/configure b/gdb/configure index 98cd488a737..f6e8a387172 100755 --- a/gdb/configure +++ b/gdb/configure @@ -765,6 +765,7 @@ ENABLE_BFD_64_BIT_TRUE subdirs GDB_DATADIR DEBUGDIR +TEXI2DVI_EXTRA_FLAGS MAKEINFO_EXTRA_FLAGS MAKEINFOFLAGS MAKEINFO @@ -11499,7 +11500,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 11502 "configure" +#line 11503 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -11605,7 +11606,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 11608 "configure" +#line 11609 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -24601,6 +24602,34 @@ if test x"$gdb_cv_have_makeinfo_click" = xyes; then fi +## Figure out if texi2dvi supports the --build option. Older versions +## didn't. If this option is not supported then parallel building in +## the docs/ directory is probably going to be broken. But single +## threaded build should be fine. +TEXI2DVI=texi2dvi +TEXI2DVI_EXTRA_FLAGS="" +{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $TEXI2DVI supports --build" >&5 +$as_echo_n "checking whether $TEXI2DVI supports --build... " >&6; } +if ${gdb_cv_have_texi2dvi_build_opt+:} false; then : + $as_echo_n "(cached) " >&6 +else + echo '\input texinfo' >conftest.texi + echo 'abc' >>conftest.texi + echo '@bye' >>conftest.texi + cp conftest.texi /home/andrew/tmp/ + if eval "$TEXI2DVI --build=tidy conftest.texi >&5 2>&5"; then + gdb_cv_have_texi2dvi_build_opt=yes + else + gdb_cv_have_texi2dvi_build_opt=no + fi +fi +{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $gdb_cv_have_texi2dvi_build_opt" >&5 +$as_echo "$gdb_cv_have_texi2dvi_build_opt" >&6; } +if test x"$gdb_cv_have_texi2dvi_build_opt" = xyes; then + TEXI2DVI_EXTRA_FLAGS="$TEXI2DVI_EXTRA_FLAGS --build=tidy" +fi + + # Check whether --with-separate-debug-dir was given. diff --git a/gdb/configure.ac b/gdb/configure.ac index 62ff09cea20..3b726e5f0aa 100644 --- a/gdb/configure.ac +++ b/gdb/configure.ac @@ -117,6 +117,27 @@ if test x"$gdb_cv_have_makeinfo_click" = xyes; then fi AC_SUBST(MAKEINFO_EXTRA_FLAGS) +## Figure out if texi2dvi supports the --build option. Older versions +## didn't. If this option is not supported then parallel building in +## the docs/ directory is probably going to be broken. But single +## threaded build should be fine. +TEXI2DVI=texi2dvi +TEXI2DVI_EXTRA_FLAGS="" +AC_CACHE_CHECK([whether $TEXI2DVI supports --build], gdb_cv_have_texi2dvi_build_opt, + [echo '\input texinfo' >conftest.texi + echo 'abc' >>conftest.texi + echo '@bye' >>conftest.texi + cp conftest.texi /home/andrew/tmp/ + if eval "$TEXI2DVI --build=tidy conftest.texi >&5 2>&5"; then + gdb_cv_have_texi2dvi_build_opt=yes + else + gdb_cv_have_texi2dvi_build_opt=no + fi]) +if test x"$gdb_cv_have_texi2dvi_build_opt" = xyes; then + TEXI2DVI_EXTRA_FLAGS="$TEXI2DVI_EXTRA_FLAGS --build=tidy" +fi +AC_SUBST(TEXI2DVI_EXTRA_FLAGS) + GDB_AC_WITH_DIR(DEBUGDIR, separate-debug-dir, [look for global separate debug info in this path @<:@LIBDIR/debug@:>@], [${libdir}/debug]) diff --git a/gdb/doc/Makefile.in b/gdb/doc/Makefile.in index c05e561edeb..5836d6ce024 100644 --- a/gdb/doc/Makefile.in +++ b/gdb/doc/Makefile.in @@ -68,6 +68,8 @@ TEXI2ROFF=texi2roff # where to find texi2dvi, ditto TEXI2DVI=texi2dvi +TEXI2DVI_EXTRA_FLAGS=@TEXI2DVI_EXTRA_FLAGS@ +TEXI2DVI_CMD = $(TEXI2DVI) $(TEXI2DVI_EXTRA_FLAGS) # Package to install the docs under PACKAGE = @PACKAGE@ @@ -481,21 +483,26 @@ gdb-cfg.texi: ${srcdir}/${DOC_CONFIG}-cfg.texi # Clean these up before each run. Avoids a catch 22 with not being # able to re-generate these files (to fix a corruption) because these # files contain a corruption. +# +# If TEXI2DVI_CMD includes the --build option then these files should +# not be created in the current directory, but attempting to delete +# them is harmless. GDB_TEX_TMPS = gdb.aux gdb.cp* gdb.fn* gdb.ky* gdb.log gdb.pg* gdb.toc \ gdb.tp* gdb.vr* # GDB MANUAL: TeX dvi file gdb.dvi: ${GDB_DOC_FILES} - $(SILENCE) rm -f $(GDB_TEX_TMPS) - $(ECHO_TEXI2DVI) $(TEXI2DVI) $(SILENT_Q_FLAG) $(READLINE_TEXI_INCFLAG) \ - -I ${GDBMI_DIR} -I $(srcdir) $(srcdir)/gdb.texinfo + $(SILENCE) rm -fr $(GDB_TEX_TMPS) gdb.t2d/dvi/ + $(ECHO_TEXI2DVI) $(TEXI2DVI_CMD) $(SILENT_Q_FLAG) \ + $(READLINE_TEXI_INCFLAG) -I ${GDBMI_DIR} -I $(srcdir) \ + $(srcdir)/gdb.texinfo gdb.ps: gdb.dvi $(ECHO_DVIPS) $(DVIPS) $(SILENT_Q_FLAG) -o $@ $? gdb.pdf: ${GDB_DOC_FILES} - $(SILENCE) rm -f $(GDB_TEX_TMPS) - $(ECHO_TEXI2DVI) $(TEXI2DVI) $(SILENT_Q_FLAG) --pdf \ + $(SILENCE) rm -fr $(GDB_TEX_TMPS) gdb.t2d/pdf/ + $(ECHO_TEXI2DVI) $(TEXI2DVI_CMD) $(SILENT_Q_FLAG) --pdf \ $(READLINE_TEXI_INCFLAG) -I ${GDBMI_DIR} -I $(srcdir) \ $(srcdir)/gdb.texinfo @@ -596,41 +603,49 @@ stabs/index.html: $(STABS_DOC_FILES) # Clean these up before each run. Avoids a catch 22 with not being # able to re-generate these files (to fix a corruption) because these # files contain a corruption. +# +# If TEXI2DVI_CMD includes the --build option then these files should +# not be created in the current directory, but attempting to delete +# them is harmless. STABS_TEX_TMPS = stabs.aux stabs.cp* stabs.fn* stabs.ky* \ stabs.log stabs.pg* stabs.toc stabs.tp* stabs.vr* # STABS DOCUMENTATION: TeX dvi file stabs.dvi : $(STABS_DOC_FILES) - $(SILENCE) rm -f $(STABS_TEX_TMPS) - $(ECHO_TEXI2DVI) $(TEXI2DVI) $(SILENT_Q_FLAG) -I $(srcdir) \ + $(SILENCE) rm -fr $(STABS_TEX_TMPS) stabs.t2d/dvi/ + $(ECHO_TEXI2DVI) $(TEXI2DVI_CMD) $(SILENT_Q_FLAG) -I $(srcdir) \ $(srcdir)/stabs.texinfo stabs.ps: stabs.dvi $(ECHO_DVIPS) $(DVIPS) $(SILENT_Q_FLAG) -o $@ $? stabs.pdf: $(STABS_DOC_FILES) - $(SILENCE) rm -f $(STABS_TEX_TMPS) - $(ECHO_TEXI2DVI) $(TEXI2DVI) $(SILENT_Q_FLAG) --pdf -I $(srcdir) \ + $(SILENCE) rm -fr $(STABS_TEX_TMPS) stabs.t2d/pdf/ + $(ECHO_TEXI2DVI) $(TEXI2DVI_CMD) $(SILENT_Q_FLAG) --pdf -I $(srcdir) \ $(srcdir)/stabs.texinfo # Clean these up before each run. Avoids a catch 22 with not being # able to re-generate these files (to fix a corruption) because these # files contain a corruption. +# +# If TEXI2DVI_CMD includes the --build option then these files should +# not be created in the current directory, but attempting to delete +# them is harmless. ANNOTATE_TEX_TMPS = annotate.aux annotate.cp* annotate.fn* annotate.ky* \ annotate.log annotate.pg* annotate.toc annotate.tp* annotate.vr* # ANNOTATE DOCUMENTATION: TeX dvi file annotate.dvi : $(ANNOTATE_DOC_FILES) - $(SILENCE) rm -f $(ANNOTATE_TEX_TMPS) - $(ECHO_TEXI2DVI) $(TEXI2DVI) $(SILENT_Q_FLAG) -I $(srcdir) \ + $(SILENCE) rm -fr $(ANNOTATE_TEX_TMPS) annotate.t2d/dvi/ + $(ECHO_TEXI2DVI) $(TEXI2DVI_CMD) $(SILENT_Q_FLAG) -I $(srcdir) \ $(srcdir)/annotate.texinfo annotate.ps: annotate.dvi $(ECHO_DVIPS) $(DVIPS) $(SILENT_Q_FLAG) -o $@ $? annotate.pdf: $(ANNOTATE_DOC_FILES) - $(SILENCE) rm -f $(ANNOTATE_TEX_TMPS) - $(ECHO_TEXI2DVI) $(TEXI2DVI) $(SILENT_Q_FLAG) --pdf -I $(srcdir) \ + $(SILENCE) rm -fr $(ANNOTATE_TEX_TMPS) annotate.t2d/pdf/ + $(ECHO_TEXI2DVI) $(TEXI2DVI_CMD) $(SILENT_Q_FLAG) --pdf -I $(srcdir) \ $(srcdir)/annotate.texinfo annotate.info: $(ANNOTATE_DOC_FILES) @@ -665,6 +680,7 @@ Makefile: Makefile.in $(host_makefile_frag) ../config.status mostlyclean: rm -f gdb.mm gdb.ms gdb.me links2roff + rm -fr annotate.t2d/ stabs.t2d/ gdb.t2d/ rm -f $(GDB_TEX_TMPS) rm -f $(STABS_TEX_TMPS) rm -f $(ANNOTATE_TEX_TMPS) -- 2.25.4 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 4/4] gdb/doc: fix parallel build of pdf and dvi files 2024-05-11 9:37 ` [PATCH 4/4] gdb/doc: fix parallel build of pdf and dvi files Andrew Burgess @ 2024-05-13 16:18 ` Tom Tromey 2024-05-14 13:40 ` Andrew Burgess 0 siblings, 1 reply; 42+ messages in thread From: Tom Tromey @ 2024-05-13 16:18 UTC (permalink / raw) To: Andrew Burgess; +Cc: gdb-patches >>>>> "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. Anyway the patch seems ok to me. The configure check is maybe overkill IMO but considering that it exists it also seems ok. Approved-By: Tom Tromey <tom@tromey.com> Tom ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 4/4] gdb/doc: fix parallel build of pdf and dvi files 2024-05-13 16:18 ` Tom Tromey @ 2024-05-14 13:40 ` Andrew Burgess 0 siblings, 0 replies; 42+ messages in thread From: Andrew Burgess @ 2024-05-14 13:40 UTC (permalink / raw) To: Tom Tromey; +Cc: gdb-patches 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCHv2 0/5] gdb/doc: parallel build fixes and improvements 2024-05-11 9:37 [PATCH 0/4] gdb/doc: build fixes and improvements Andrew Burgess ` (3 preceding siblings ...) 2024-05-11 9:37 ` [PATCH 4/4] gdb/doc: fix parallel build of pdf and dvi files Andrew Burgess @ 2024-05-31 8:18 ` Andrew Burgess 2024-05-31 8:18 ` [PATCHv2 1/5] gdb/doc: don't try to copy GDBvn.texi from the source tree Andrew Burgess ` (5 more replies) 4 siblings, 6 replies; 42+ messages in thread From: Andrew Burgess @ 2024-05-31 8:18 UTC (permalink / raw) To: gdb-patches; +Cc: Andrew Burgess After feedback on the v1 series I merged the first patch. I've now rewritten the commit message for what was the second patch to better explain why this change is fine. I've added some additional fixes I found, these are the new patches #2 and #3, then the final two patches are unchanged from v1 (and already got approved). The goal of this series is to fix 'make -j20 -C gdb/doc all-doc', but I've also fixed some doc rebuild issues that currently exist with our releases. For testing, as well as a parallel build of 'all-doc' in a git checkout, I've also been creating a GDB release tar file, unpacking that into an empty directory and doing the usual configure, make, 'make install' process to ensure that works fine. The things I'm checking for in this last step are: 1. From a freshly unpacked GDB release, by default we don't build the man or info pages when doing make and 'make install', we just install the copies in the source tree. 2. If I then 'touch gdb/doc/*.texinfo' in the unpacked release tree and then 'make install' the info and man pages are successfully rebuilt using the GDBvn.texi and version.subst files in the source tree. 3. If I 'touch gdb/doc/version.subst' then 'make install' we correctly recreate GDBvn.texi in the build directory and then rebuild the docs using this new file. 4. And finally, if I 'touch bfd/version.h' then 'make install' we correctly rebuild version.subst into the build directory and then rebuild everything using this file. Steps 2, 3, and 4 don't currently work with previous GDB releases. In V2: - Patch #1: the content of this patch is unchanged from v1, however the commit message is completely rewritten. I believe the change I made was good, but my previous justification was completely wrong! - Patches #2 and #3: these patches are completely new in v2. - Patches #4 and #5: these are completely unchanged from v1 where they were already approved. Further feedback is of course welcome, but if you want to skip looking at these, that's fine too. Thanks, Andrew --- Andrew Burgess (5): gdb/doc: don't try to copy GDBvn.texi from the source tree gdb/doc: allow for version.subst in the source tree gdb/doc: also look in srcdir when running TEXI2POD gdb/doc: fix parallel build of refcard related targets gdb/doc: fix parallel build of pdf and dvi files gdb/configure | 33 +++++++++++- gdb/configure.ac | 21 ++++++++ gdb/doc/Makefile.in | 121 ++++++++++++++++++++++++-------------------- 3 files changed, 118 insertions(+), 57 deletions(-) base-commit: 40acbd34527648e0c375b965b16ab5b7f2ecae6c -- 2.25.4 ^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCHv2 1/5] gdb/doc: don't try to copy GDBvn.texi from the source tree 2024-05-31 8:18 ` [PATCHv2 0/5] gdb/doc: parallel build fixes and improvements Andrew Burgess @ 2024-05-31 8:18 ` Andrew Burgess 2024-05-31 8:18 ` [PATCHv2 2/5] gdb/doc: allow for version.subst in " Andrew Burgess ` (4 subsequent siblings) 5 siblings, 0 replies; 42+ messages in thread From: Andrew Burgess @ 2024-05-31 8:18 UTC (permalink / raw) To: gdb-patches; +Cc: Andrew Burgess The build recipe for gdb.dvi and gdb.pdf contains instructions for copying the GDBvn.texi file from the source tree into the build directory if the GDBvn.texi file doesn't already exist in the build directory. The gdb.dvi and gdb.pdf targets also have a dependency on GDBvn.texi, and we have a recipe for building GDBvn.texi. What's happening here is this: - In a git checkout of the source tree there is no GDBvn.texi in the source tree, the GDBvn.texi dependency will trigger a rebuild of GDBvn.texi, which is then used to build gdb.dvi and/or gdb.pdf. - In a release tar file we do include a copy of GDBvn.texi. This file will appear to be up to date, and so no copy of GDBvn.texi is created within the build directory. Now when building gdb.dvi and/or gdb.pdf we copy (or symlink) the version of GDBvn.texi from the source tree into the build directory. However, copying GDBvn.texi into the source directory is completely unnecessary. The gdb.dvi/gdb.pdf recipes both invoke texi2dvi and pass '-I $(srcdir)' as an argument, this means that texi2dvi will look in the $(srcdir) to find included files, including GDBvn.texi. As such I believe we can remove the code that copies GDBvn.texi from the source tree into the build tree. I've tested with a release build; creating a release with: ./src-release gdb Then in an empty directory, unpacking the resulting .tar file, creating a parallel build directory and doing the usual configure, make, and 'make install'. Having done this I can then 'touch gdb/doc/*.texinfo' in the unpacked source tree, and do 'make -C gdb/doc pdf dvi' to rebuild all the pdf and dvi files, this works fine without having to either build or copy GDBvn.texi into the build directory. --- gdb/doc/Makefile.in | 17 ----------------- 1 file changed, 17 deletions(-) diff --git a/gdb/doc/Makefile.in b/gdb/doc/Makefile.in index 6a112b98d0e..3a179e9799a 100644 --- a/gdb/doc/Makefile.in +++ b/gdb/doc/Makefile.in @@ -477,15 +477,6 @@ gdb-cfg.texi: ${srcdir}/${DOC_CONFIG}-cfg.texi ln ${srcdir}/${DOC_CONFIG}-cfg.texi gdb-cfg.texi || \ cp ${srcdir}/${DOC_CONFIG}-cfg.texi gdb-cfg.texi -# GDB MANUAL: texinfo source, using @set/@clear/@value/@ifset/@ifclear -# If your texinfo or makeinfo don't support these, get a new texinfo release -# -# The nonsense with GDBvn.texi gets this to run with both Sun and GNU make. -# Note that we can *generate* GDBvn.texi, but since we distribute one in the -# source directory for the benefit of people who *don't* use this makefile, -# VPATH will often tell make not to bother building it, because the one -# in the srcdir is up to date. (if not, then make should build one here). - # Clean these up before each run. Avoids a catch 22 with not being # able to re-generate these files (to fix a corruption) because these # files contain a corruption. @@ -494,10 +485,6 @@ GDB_TEX_TMPS = gdb.aux gdb.cp* gdb.fn* gdb.ky* gdb.log gdb.pg* gdb.toc \ # GDB MANUAL: TeX dvi file gdb.dvi: ${GDB_DOC_FILES} - $(SILENCE) if [ ! -f ./GDBvn.texi ]; then \ - (test "$(LN_S)" = "ln -s" && ln -s $(srcdir)/GDBvn.texi .) || \ - ln $(srcdir)/GDBvn.texi . || \ - cp $(srcdir)/GDBvn.texi . ; else true; fi $(SILENCE) rm -f $(GDB_TEX_TMPS) $(ECHO_TEXI2DVI) $(TEXI2DVI) $(SILENT_Q_FLAG) $(READLINE_TEXI_INCFLAG) \ -I ${GDBMI_DIR} -I $(srcdir) $(srcdir)/gdb.texinfo @@ -506,10 +493,6 @@ gdb.ps: gdb.dvi $(ECHO_DVIPS) $(DVIPS) $(SILENT_Q_FLAG) -o $@ $? gdb.pdf: ${GDB_DOC_FILES} - $(SILENCE) if [ ! -f ./GDBvn.texi ]; then \ - (test "$(LN_S)" = "ln -s" && ln -s $(srcdir)/GDBvn.texi .) || \ - ln $(srcdir)/GDBvn.texi . || \ - cp $(srcdir)/GDBvn.texi . ; else true; fi $(SILENCE) rm -f $(GDB_TEX_TMPS) $(ECHO_TEXI2DVI) $(TEXI2DVI) $(SILENT_Q_FLAG) --pdf \ $(READLINE_TEXI_INCFLAG) -I ${GDBMI_DIR} -I $(srcdir) \ -- 2.25.4 ^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCHv2 2/5] gdb/doc: allow for version.subst in the source tree 2024-05-31 8:18 ` [PATCHv2 0/5] gdb/doc: parallel build fixes and improvements Andrew Burgess 2024-05-31 8:18 ` [PATCHv2 1/5] gdb/doc: don't try to copy GDBvn.texi from the source tree Andrew Burgess @ 2024-05-31 8:18 ` Andrew Burgess 2024-05-31 10:40 ` Eli Zaretskii 2024-05-31 8:18 ` [PATCHv2 3/5] gdb/doc: also look in srcdir when running TEXI2POD Andrew Burgess ` (3 subsequent siblings) 5 siblings, 1 reply; 42+ messages in thread From: Andrew Burgess @ 2024-05-31 8:18 UTC (permalink / raw) To: gdb-patches; +Cc: Andrew Burgess In a git checkout of the source code we don't have a version.subst file in the gdb/doc directory. When building the GDB docs the version.subst file is generated on demand (we have a recipe for that). However, in a release tar file we do include a copy of the version.subst file in the source tree, as a result the version.subst recipe will not be run. If, in a release build, we force the running of any recipe that depends on version.subst then we run into a problem. For example, slightly confusingly, if we 'touch gdb/doc/version.subst' within the unpacked source tree of a release, then 'make -C gdb/doc GDBvn.texi' in the build tree, we'll see: make: Entering directory '/tmp/build/build/gdb/doc' GEN GDBvn.texi sed: can't read version.subst: No such file or directory make: Leaving directory '/tmp/build/build/gdb/doc' The problem is that every reference to version.subst in GDB's Makefile assumes that the version.subst file will always be in the build directory. In this commit I replace direct references to version.subst with a small shell snippet which returns the path to the version.subst file to use. If there is a version.subst file in the build directory then that file is selected, otherwise we return the path to a version.subst file in the source directory. As the POD2MAN1 and POD2MAN5 commands both depend on version.subst I have added version.subst as a dependency to the two recipes that use this variable. --- gdb/doc/Makefile.in | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/gdb/doc/Makefile.in b/gdb/doc/Makefile.in index 3a179e9799a..e5f8a11008e 100644 --- a/gdb/doc/Makefile.in +++ b/gdb/doc/Makefile.in @@ -178,10 +178,21 @@ MANCONF = -Dman TEXI2POD = perl $(srcdir)/../../etc/texi2pod.pl \ $(MAKEINFOFLAGS) $(MAKEINFO_EXTRA_FLAGS) +# Shell snippet which will provide the full filename of the +# version.subst file to use. If there is a copy in the build +# directory then that is preferred, otherwise we assume there is a +# copy in the source tree. +VERSION_SUBST = $$(if [ -r version.subst ]; \ + then \ + (echo $$PWD/version.subst); \ + else \ + (builtin cd $(srcdir) && echo $$PWD/version.subst); \ + fi) + POD2MAN1 = pod2man --center="GNU Development Tools" \ - --release="gdb-`sed q version.subst`" --section=1 + --release="gdb-`sed q $(VERSION_SUBST)`" --section=1 POD2MAN5 = pod2man --center="GNU Development Tools" \ - --release="gdb-`sed q version.subst`" --section=5 + --release="gdb-`sed q $(VERSION_SUBST)`" --section=5 # List of man pages generated from gdb.texi MAN1S = gdb.1 gdbserver.1 gcore.1 gdb-add-index.1 @@ -439,7 +450,7 @@ refcard.pdf : refcard.tex $(REFEDITS) # File to record current GDB version number. GDBvn.texi : version.subst $(ECHO_GEN) - $(SILENCE) echo "@set GDBVN `sed q version.subst`" > ./GDBvn.new + $(SILENCE) echo "@set GDBVN `sed q $(VERSION_SUBST)`" > ./GDBvn.new $(SILENCE) if [ -n "$(PKGVERSION)" ]; then \ echo "@set VERSION_PACKAGE $(PKGVERSION)" >> ./GDBvn.new; \ fi @@ -654,13 +665,13 @@ annotate/index.html: $(ANNOTATE_DOC_FILES) # pages, then the .pod files must become a dependency, this will # trigger an attempt to rebuild these files while building and # installing a release of GDB, which is something we don't want. -$(MAN1S) : %.1 : $(GDB_DOC_FILES) +$(MAN1S) : %.1 : $(GDB_DOC_FILES) version.subst $(ECHO_TEXI2POD) $(TEXI2POD) $(MANCONF) -D$* < $(srcdir)/gdb.texinfo > $*.pod $(ECHO_TEXI2MAN) ($(POD2MAN1) $*.pod | sed -e '/^.if n .na/d' > $@.T$$$$ && \ mv -f $@.T$$$$ $@) || (rm -f $@.T$$$$ && exit 1) $(SILENCE) rm -f $*.pod -$(MAN5S) : %.5 : $(GDB_DOC_FILES) +$(MAN5S) : %.5 : $(GDB_DOC_FILES) version.subst $(ECHO_TEXI2POD) $(TEXI2POD) $(MANCONF) -D$* < $(srcdir)/gdb.texinfo > $*.pod $(ECHO_TEXI2MAN) ($(POD2MAN1) $*.pod | sed -e '/^.if n .na/d' > $@.T$$$$ && \ mv -f $@.T$$$$ $@) || (rm -f $@.T$$$$ && exit 1) -- 2.25.4 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCHv2 2/5] gdb/doc: allow for version.subst in the source tree 2024-05-31 8:18 ` [PATCHv2 2/5] gdb/doc: allow for version.subst in " Andrew Burgess @ 2024-05-31 10:40 ` Eli Zaretskii 2024-06-03 14:22 ` Andrew Burgess 0 siblings, 1 reply; 42+ messages in thread From: Eli Zaretskii @ 2024-05-31 10:40 UTC (permalink / raw) To: Andrew Burgess; +Cc: gdb-patches, aburgess > From: Andrew Burgess <aburgess@redhat.com> > Cc: Andrew Burgess <aburgess@redhat.com> > Date: Fri, 31 May 2024 09:18:39 +0100 > > In a git checkout of the source code we don't have a version.subst > file in the gdb/doc directory. When building the GDB docs the > version.subst file is generated on demand (we have a recipe for that). > > However, in a release tar file we do include a copy of the > version.subst file in the source tree, as a result the version.subst > recipe will not be run. > > If, in a release build, we force the running of any recipe that > depends on version.subst then we run into a problem. For example, > slightly confusingly, if we 'touch gdb/doc/version.subst' within the > unpacked source tree of a release, then 'make -C gdb/doc GDBvn.texi' > in the build tree, we'll see: > > make: Entering directory '/tmp/build/build/gdb/doc' > GEN GDBvn.texi > sed: can't read version.subst: No such file or directory > make: Leaving directory '/tmp/build/build/gdb/doc' > > The problem is that every reference to version.subst in GDB's Makefile > assumes that the version.subst file will always be in the build > directory. > > In this commit I replace direct references to version.subst with a > small shell snippet which returns the path to the version.subst file > to use. If there is a version.subst file in the build directory then > that file is selected, otherwise we return the path to a version.subst > file in the source directory. Why isn't VPATH or vpath enough to solve this nuisance? Alternatively, how about copying version.subst from the source tree to the build tree if it is absent from the build tree? Thanks. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCHv2 2/5] gdb/doc: allow for version.subst in the source tree 2024-05-31 10:40 ` Eli Zaretskii @ 2024-06-03 14:22 ` Andrew Burgess 2024-06-06 11:59 ` Eli Zaretskii 0 siblings, 1 reply; 42+ messages in thread From: Andrew Burgess @ 2024-06-03 14:22 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb-patches Eli Zaretskii <eliz@gnu.org> writes: >> From: Andrew Burgess <aburgess@redhat.com> >> Cc: Andrew Burgess <aburgess@redhat.com> >> Date: Fri, 31 May 2024 09:18:39 +0100 >> >> In a git checkout of the source code we don't have a version.subst >> file in the gdb/doc directory. When building the GDB docs the >> version.subst file is generated on demand (we have a recipe for that). >> >> However, in a release tar file we do include a copy of the >> version.subst file in the source tree, as a result the version.subst >> recipe will not be run. >> >> If, in a release build, we force the running of any recipe that >> depends on version.subst then we run into a problem. For example, >> slightly confusingly, if we 'touch gdb/doc/version.subst' within the >> unpacked source tree of a release, then 'make -C gdb/doc GDBvn.texi' >> in the build tree, we'll see: >> >> make: Entering directory '/tmp/build/build/gdb/doc' >> GEN GDBvn.texi >> sed: can't read version.subst: No such file or directory >> make: Leaving directory '/tmp/build/build/gdb/doc' >> >> The problem is that every reference to version.subst in GDB's Makefile >> assumes that the version.subst file will always be in the build >> directory. >> >> In this commit I replace direct references to version.subst with a >> small shell snippet which returns the path to the version.subst file >> to use. If there is a version.subst file in the build directory then >> that file is selected, otherwise we return the path to a version.subst >> file in the source directory. > > Why isn't VPATH or vpath enough to solve this nuisance? If anything VPATH is the _cause_ of this nuisance! With the VPATH set as it is, make will check both the build directory and the source directory. So when we have a rule like: some_target : version.subst some_command version.subst make is going to look for the version.subst dependency in both locations, however, where 'some_command' looks is entirely up to 'some_command'. In our case for example, the 'sed' command doesn't (to my knowledge) have a search path command line option, so a command like: sed q version.subst is only going to search in the build directory. Another file that has this problem is GDBvn.texi, however, all the commands that consume this file support a '-I dir' command line flag to add a search path, and so for those commands we add '-I $srcdir' so the command will look in the source directory. > Alternatively, how about copying version.subst from the source tree to > the build tree if it is absent from the build tree? That for sure would be possible. We would need to take care to ensure that the modification time on the file wasn't changed, e.g. if we had to copy from one filesystem to another, as GDBvn.texi depends on version.subst, and most of the other doc files depend on GDBvn.texi, and as you pointed out in an earlier email, we don't want to end up triggering a doc rebuild for a release build/install. The other problem is copying/moving the file from the source tree is for parallel builds. Multiple recipes use version.subst, so each of those would I think need to include the logic for copying the file. And would need to ensure that the copy was (a) atomic, and (b) didn't result in an error if another recipe completed before us... otherwise we'd see random errors from a parallel build. I did wonder if we could create a hard dependency on $(builddir)/version.subst, but I have no idea how I could make that work, we need to copy the file from the $(srcdir) only if its up to date, otherwise we need to rebuild the file. And we'd still need to solve the problem that if targets depended on $(builddir)/version.subst which would certainly not exist in a release, then this would trigger a complete rebuild of the docs, which violates a hard requirement. I agree that the solution proposed here is not ideal ... but I'm not sure anything else is better. Thanks, Andrew ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCHv2 2/5] gdb/doc: allow for version.subst in the source tree 2024-06-03 14:22 ` Andrew Burgess @ 2024-06-06 11:59 ` Eli Zaretskii 2024-06-06 17:52 ` Andrew Burgess 0 siblings, 1 reply; 42+ messages in thread From: Eli Zaretskii @ 2024-06-06 11:59 UTC (permalink / raw) To: Andrew Burgess; +Cc: gdb-patches > From: Andrew Burgess <aburgess@redhat.com> > Cc: gdb-patches@sourceware.org > Date: Mon, 03 Jun 2024 15:22:41 +0100 > > Eli Zaretskii <eliz@gnu.org> writes: > > >> make: Entering directory '/tmp/build/build/gdb/doc' > >> GEN GDBvn.texi > >> sed: can't read version.subst: No such file or directory > >> make: Leaving directory '/tmp/build/build/gdb/doc' > >> > >> The problem is that every reference to version.subst in GDB's Makefile > >> assumes that the version.subst file will always be in the build > >> directory. > >> > >> In this commit I replace direct references to version.subst with a > >> small shell snippet which returns the path to the version.subst file > >> to use. If there is a version.subst file in the build directory then > >> that file is selected, otherwise we return the path to a version.subst > >> file in the source directory. > > > > Why isn't VPATH or vpath enough to solve this nuisance? > > If anything VPATH is the _cause_ of this nuisance! With the VPATH set > as it is, make will check both the build directory and the source > directory. So when we have a rule like: > > some_target : version.subst > some_command version.subst > > make is going to look for the version.subst dependency in both > locations, however, where 'some_command' looks is entirely up to > 'some_command'. In our case for example, the 'sed' command doesn't (to > my knowledge) have a search path command line option, so a command like: > > sed q version.subst > > is only going to search in the build directory. My reading of the node "Recipes/Search" in the GNU Make manual is that if you use automatic variables, such as $^, in the recipe, Make will expand the variable into the full file name including the directory in which it found the file via VPATH search. Can't we use that feature here? IOW, instead of some_target : version.subst some_command version.subst you should use something like some_target : version.subst some_command $< > I agree that the solution proposed here is not ideal ... but I'm not > sure anything else is better. How about the above, assuming it works? ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCHv2 2/5] gdb/doc: allow for version.subst in the source tree 2024-06-06 11:59 ` Eli Zaretskii @ 2024-06-06 17:52 ` Andrew Burgess 0 siblings, 0 replies; 42+ messages in thread From: Andrew Burgess @ 2024-06-06 17:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb-patches Eli Zaretskii <eliz@gnu.org> writes: >> From: Andrew Burgess <aburgess@redhat.com> >> Cc: gdb-patches@sourceware.org >> Date: Mon, 03 Jun 2024 15:22:41 +0100 >> >> Eli Zaretskii <eliz@gnu.org> writes: >> >> >> make: Entering directory '/tmp/build/build/gdb/doc' >> >> GEN GDBvn.texi >> >> sed: can't read version.subst: No such file or directory >> >> make: Leaving directory '/tmp/build/build/gdb/doc' >> >> >> >> The problem is that every reference to version.subst in GDB's Makefile >> >> assumes that the version.subst file will always be in the build >> >> directory. >> >> >> >> In this commit I replace direct references to version.subst with a >> >> small shell snippet which returns the path to the version.subst file >> >> to use. If there is a version.subst file in the build directory then >> >> that file is selected, otherwise we return the path to a version.subst >> >> file in the source directory. >> > >> > Why isn't VPATH or vpath enough to solve this nuisance? >> >> If anything VPATH is the _cause_ of this nuisance! With the VPATH set >> as it is, make will check both the build directory and the source >> directory. So when we have a rule like: >> >> some_target : version.subst >> some_command version.subst >> >> make is going to look for the version.subst dependency in both >> locations, however, where 'some_command' looks is entirely up to >> 'some_command'. In our case for example, the 'sed' command doesn't (to >> my knowledge) have a search path command line option, so a command like: >> >> sed q version.subst >> >> is only going to search in the build directory. > > My reading of the node "Recipes/Search" in the GNU Make manual is that > if you use automatic variables, such as $^, in the recipe, Make will > expand the variable into the full file name including the directory in > which it found the file via VPATH search. Can't we use that feature > here? IOW, instead of > > some_target : version.subst > some_command version.subst > > you should use something like > > some_target : version.subst > some_command $< Thanks. I was completely unaware that $< (and friends) worked like this... but I guess it makes sense when you think about it. This is indeed a better way to solve the problem I had. While working on this change I ended up adding a whole extra patch to the series, so I've followed up with a V3 series. Thanks for your patience. Andrew ^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCHv2 3/5] gdb/doc: also look in srcdir when running TEXI2POD 2024-05-31 8:18 ` [PATCHv2 0/5] gdb/doc: parallel build fixes and improvements Andrew Burgess 2024-05-31 8:18 ` [PATCHv2 1/5] gdb/doc: don't try to copy GDBvn.texi from the source tree Andrew Burgess 2024-05-31 8:18 ` [PATCHv2 2/5] gdb/doc: allow for version.subst in " Andrew Burgess @ 2024-05-31 8:18 ` Andrew Burgess 2024-05-31 8:18 ` [PATCHv2 4/5] gdb/doc: fix parallel build of refcard related targets Andrew Burgess ` (2 subsequent siblings) 5 siblings, 0 replies; 42+ messages in thread From: Andrew Burgess @ 2024-05-31 8:18 UTC (permalink / raw) To: gdb-patches; +Cc: Andrew Burgess In gdb/doc/Makefile.in the TEXI2POD variable is used to invoke texi2pod.pl, which process the .texinfo files. This also handles the 'include' directives within the .texinfo files. Like the texi2dvi and texi2pdf tools, texi2pod.pl handles the -I flag to add search directories for resolving 'include' directives within .texinfo files. When GDB runs TEXI2POD we include gdb-cfg.texi, which then includes GDBvn.texi. When building from a git checkout the gdb-cfg.texi files and GDBvn.texi files will be created in the build directory, which is where texi2pod.pl is invoked, so the files will be found just fine. However, for a GDB release we ship gdb-cfg.texi and GDBvn.texi in the source tree, along with the generated manual (.1 and .5) files. So when building a release, what normally happens is that we spot that the .1 and .5 man files are up to date, and don't run the recipe to regenerate these files. However, if we deliberately touch the *.texinfo files in a release source tree, and then try to rebuild the man files, we'll get an error like this: make: Entering directory '/tmp/release-build/build/gdb/doc' TEXI2POD gdb.1 cannot find GDBvn.texi at ../../../gdb-16.0.50.20240529/gdb/doc/../../etc/texi2pod.pl line 251, <GEN0> line 16. make: *** [Makefile:664: gdb.1] Error 2 make: Leaving directory '/tmp/release-build/build/gdb/doc' The problem is that texi2pod.pl doesn't know to look in the source tree for the GDBvn.texi file. If we compare this to the recipe for creating (for example) gdb.dvi, which uses texi2dvi, this recipe adds '-I $(srcdir)' to the texi2dvi command line, which allows texi2dvi to find GDBvn.texi in the source tree. In this commit I add a similar -I option to the texi2pod.pl command line. After this, given a GDB release, it is possible to edit (or just touch) the gdb.texinfo file and rebuild the man pages, the GDBvn.texi will be picked up from the source tree. If however a dependency for GDBvn.texi is changed in a release tree then GDBvn.texi will be regenerated into the build directory and this will be picked up in preference to the GDBvn.texi in the source tree, just as you would want. --- gdb/doc/Makefile.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gdb/doc/Makefile.in b/gdb/doc/Makefile.in index e5f8a11008e..e5304404ba8 100644 --- a/gdb/doc/Makefile.in +++ b/gdb/doc/Makefile.in @@ -176,7 +176,7 @@ ANNOTATE_DOC_FILES = \ MANCONF = -Dman TEXI2POD = perl $(srcdir)/../../etc/texi2pod.pl \ - $(MAKEINFOFLAGS) $(MAKEINFO_EXTRA_FLAGS) + $(MAKEINFOFLAGS) $(MAKEINFO_EXTRA_FLAGS) -I $(srcdir) # Shell snippet which will provide the full filename of the # version.subst file to use. If there is a copy in the build -- 2.25.4 ^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCHv2 4/5] gdb/doc: fix parallel build of refcard related targets 2024-05-31 8:18 ` [PATCHv2 0/5] gdb/doc: parallel build fixes and improvements Andrew Burgess ` (2 preceding siblings ...) 2024-05-31 8:18 ` [PATCHv2 3/5] gdb/doc: also look in srcdir when running TEXI2POD Andrew Burgess @ 2024-05-31 8:18 ` Andrew Burgess 2024-05-31 8:18 ` [PATCHv2 5/5] gdb/doc: fix parallel build of pdf and dvi files Andrew Burgess 2024-06-06 17:49 ` [PATCHv3 0/6] gdb/doc: parallel build fixes and improvements Andrew Burgess 5 siblings, 0 replies; 42+ messages in thread From: Andrew Burgess @ 2024-05-31 8:18 UTC (permalink / raw) To: gdb-patches; +Cc: Andrew Burgess, Tom Tromey There are two problems we encounter when trying to build the refcard related target in parallel, i.e.: $ make -j20 -C gdb/doc/ refcard.dvi refcard.ps refcard.pdf These problems are: (1) The refcard.dvi and refcard.pdf targets both try and generate the tmp.sed and sedref.tex files. If two make threads end up trying to create these files at the same time then the result is these files become corrupted. I've fixed this by creating a new rule that creates sedref.tex, both refcard.dvi and refcard.pdf now depend on this, and make will build sedref.tex just once. The tmp.sed file is now generated as refcard.sed, this is generated and deleted as a temporary file within the sedref.tex recipe. (2) Having created sedref.tex the recipes for refcard.dvi and refcard.pdf both run various LaTeX based tools with sedref.tex as the input file. The problem with this is that these tools all rely on creating temporary files calls sedref.*. If the refcard.dvi and refcard.pdf rules run at the same time then these temporary files clash and overwrite each other causing the build to fail. We already copy the result file in order to rename it, our input file is sedref.tex which results in an output file named sedref.dvi or sedref.pdf, but we actually want refcard.dvi or refcard.pdf. So within the recipe for refcard.dvi I copy the input file from sedref.tex to sedref_dvi.tex. Now all the temp files are named sedref_dvi.* and the output is sedref_dvi.dvi, I then rename this new output file to refcard.dvi. I've done the same thing for refcard.pdf, but I copy the input to sedref_pdf.tex. In this way the temp files no longer clash, and both recipes can safely run in parallel. After this commit I was able to reliably build all of the refcard targets in parallel. There should be no change in the final file. Approved-By: Tom Tromey <tom@tromey.com> --- gdb/doc/Makefile.in | 39 ++++++++++++++++++++------------------- 1 file changed, 20 insertions(+), 19 deletions(-) diff --git a/gdb/doc/Makefile.in b/gdb/doc/Makefile.in index e5304404ba8..3d64526f542 100644 --- a/gdb/doc/Makefile.in +++ b/gdb/doc/Makefile.in @@ -421,31 +421,32 @@ de-stage3: force -(cd stage3 ; mv -f * ..) -rmdir stage3 -# GDB QUICK REFERENCE (dvi output) -refcard.dvi : refcard.tex $(REFEDITS) - $(SILENCE) echo > tmp.sed + +sedref.tex : refcard.tex $(REFEDITS) + $(SILENCE) echo > refcard.sed $(SILENCE) for f in x $(REFEDITS) ; do \ test x$$f = xx && continue ; \ - cat $(srcdir)/$$f >>tmp.sed ; \ + cat $(srcdir)/$$f >>refcard.sed ; \ done - $(SILENCE) sed -f tmp.sed $(srcdir)/refcard.tex >sedref.tex - $(ECHO_TEX) $(SET_TEXINPUTS) $(TEX) sedref.tex - $(SILENCE) mv sedref.dvi refcard.dvi - $(SILENCE) rm -f sedref.log sedref.tex tmp.sed + $(ECHO_GEN) sed -f refcard.sed $(srcdir)/refcard.tex >$@ + $(SILENCE) rm -f refcard.sed + + +# GDB QUICK REFERENCE (dvi output) +refcard.dvi : sedref.tex + $(SILENCE) rm -f sedref_dvi.* + $(SILENCE) cp $< sedref_dvi.tex + $(ECHO_TEX) $(SET_TEXINPUTS) $(TEX) sedref_dvi.tex && \ + mv sedref_dvi.dvi $@ refcard.ps : refcard.dvi $(ECHO_DVIPS) $(DVIPS) $(SILENT_Q_FLAG) -t landscape -o $@ $? -refcard.pdf : refcard.tex $(REFEDITS) - $(SILENCE) echo > tmp.sed - $(SILENCE) for f in x $(REFEDITS) ; do \ - test x$$f = xx && continue ; \ - cat $(srcdir)/$$f >>tmp.sed ; \ - done - $(SILENCE) sed -f tmp.sed $(srcdir)/refcard.tex >sedref.tex - $(ECHO_PDFTEX) $(SET_TEXINPUTS) $(PDFTEX) sedref.tex - $(SILENCE) mv sedref.pdf refcard.pdf - $(SILENCE) rm -f sedref.log sedref.tex tmp.sed +refcard.pdf : sedref.tex + $(SILENCE) rm -f sedref_pdf.* + $(SILENCE) cp $< sedref_pdf.tex + $(ECHO_PDFTEX) $(SET_TEXINPUTS) $(PDFTEX) sedref_pdf.tex && \ + mv sedref_pdf.pdf $@ # File to record current GDB version number. GDBvn.texi : version.subst @@ -691,7 +692,7 @@ mostlyclean: rm -f $(GDB_TEX_TMPS) rm -f $(STABS_TEX_TMPS) rm -f $(ANNOTATE_TEX_TMPS) - rm -f sedref.dvi sedref.tex tmp.sed sedref.log + rm -f refcard.sed sedref.tex sedref_dvi.* sedref_pdf.* rm -f $(POD_FILE_TMPS) clean: mostlyclean -- 2.25.4 ^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCHv2 5/5] gdb/doc: fix parallel build of pdf and dvi files 2024-05-31 8:18 ` [PATCHv2 0/5] gdb/doc: parallel build fixes and improvements Andrew Burgess ` (3 preceding siblings ...) 2024-05-31 8:18 ` [PATCHv2 4/5] gdb/doc: fix parallel build of refcard related targets Andrew Burgess @ 2024-05-31 8:18 ` Andrew Burgess 2024-06-06 17:49 ` [PATCHv3 0/6] gdb/doc: parallel build fixes and improvements Andrew Burgess 5 siblings, 0 replies; 42+ messages in thread From: Andrew Burgess @ 2024-05-31 8:18 UTC (permalink / raw) To: gdb-patches; +Cc: Andrew Burgess, Tom Tromey When building with 'make -j20 -C gdb/doc all-doc' I often see problems caused from trying to build some dvi files in parallel with some pdf files. The problem files are: gdb.dvi and gdb.pdf; stabs.dvi and stabs.pdf; and annotate.dvi and annotate.pdf. The problem is that building these files create temporary files in the local directory. There's already a race here that two make threads might try to create these files at the same time. But it gets worse, to avoid issues where a failed build could leave these temporary files in a corrupted state, and so prevent the next build from succeeding, the recipe for each of these files delete all the temporary files first, this obviously causes problems if some other thread has already started the build and is relying on these temporary files. To work around this problem I propose we start using the --build flag for texi2dvi (which is the same tool used to create the pdf files). The --build flag allows for the temporary files to be placed into a sub-directory, e.g. creating gdb.pdf will create the temporary files in gdb.t2d/pdf/ and gdb.dvi uses gdb.t2d/dvi/, in this way the temporary files will never clash, and we can easily delete the specific sub-directory at the start of the recipe to ensure a successful build. Very old versions of texi2dvi don't support --build, so I've added a configure check for this option. If the option is not supported then we don't use it. This means we fall back to placing temporary files in the local directory, which means parallel builds will remain broken. The --build option is definitely present in texi2dvi version 6.1, from 2016, so any version after that should be fine. For me, with this fix in place, I can now run 'make -j20 -C gdb/doc all-doc' without seeing any build problems. Approved-By: Tom Tromey <tom@tromey.com> --- gdb/configure | 33 +++++++++++++++++++++++++++++++-- gdb/configure.ac | 21 +++++++++++++++++++++ gdb/doc/Makefile.in | 42 +++++++++++++++++++++++++++++------------- 3 files changed, 81 insertions(+), 15 deletions(-) diff --git a/gdb/configure b/gdb/configure index 66a7ad8d256..8d870d50de3 100755 --- a/gdb/configure +++ b/gdb/configure @@ -765,6 +765,7 @@ ENABLE_BFD_64_BIT_TRUE subdirs GDB_DATADIR DEBUGDIR +TEXI2DVI_EXTRA_FLAGS MAKEINFO_EXTRA_FLAGS MAKEINFOFLAGS MAKEINFO @@ -11499,7 +11500,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 11502 "configure" +#line 11503 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -11605,7 +11606,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 11608 "configure" +#line 11609 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -24609,6 +24610,34 @@ if test x"$gdb_cv_have_makeinfo_click" = xyes; then fi +## Figure out if texi2dvi supports the --build option. Older versions +## didn't. If this option is not supported then parallel building in +## the docs/ directory is probably going to be broken. But single +## threaded build should be fine. +TEXI2DVI=texi2dvi +TEXI2DVI_EXTRA_FLAGS="" +{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $TEXI2DVI supports --build" >&5 +$as_echo_n "checking whether $TEXI2DVI supports --build... " >&6; } +if ${gdb_cv_have_texi2dvi_build_opt+:} false; then : + $as_echo_n "(cached) " >&6 +else + echo '\input texinfo' >conftest.texi + echo 'abc' >>conftest.texi + echo '@bye' >>conftest.texi + cp conftest.texi /home/andrew/tmp/ + if eval "$TEXI2DVI --build=tidy conftest.texi >&5 2>&5"; then + gdb_cv_have_texi2dvi_build_opt=yes + else + gdb_cv_have_texi2dvi_build_opt=no + fi +fi +{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $gdb_cv_have_texi2dvi_build_opt" >&5 +$as_echo "$gdb_cv_have_texi2dvi_build_opt" >&6; } +if test x"$gdb_cv_have_texi2dvi_build_opt" = xyes; then + TEXI2DVI_EXTRA_FLAGS="$TEXI2DVI_EXTRA_FLAGS --build=tidy" +fi + + # Check whether --with-separate-debug-dir was given. diff --git a/gdb/configure.ac b/gdb/configure.ac index 62ff09cea20..3b726e5f0aa 100644 --- a/gdb/configure.ac +++ b/gdb/configure.ac @@ -117,6 +117,27 @@ if test x"$gdb_cv_have_makeinfo_click" = xyes; then fi AC_SUBST(MAKEINFO_EXTRA_FLAGS) +## Figure out if texi2dvi supports the --build option. Older versions +## didn't. If this option is not supported then parallel building in +## the docs/ directory is probably going to be broken. But single +## threaded build should be fine. +TEXI2DVI=texi2dvi +TEXI2DVI_EXTRA_FLAGS="" +AC_CACHE_CHECK([whether $TEXI2DVI supports --build], gdb_cv_have_texi2dvi_build_opt, + [echo '\input texinfo' >conftest.texi + echo 'abc' >>conftest.texi + echo '@bye' >>conftest.texi + cp conftest.texi /home/andrew/tmp/ + if eval "$TEXI2DVI --build=tidy conftest.texi >&5 2>&5"; then + gdb_cv_have_texi2dvi_build_opt=yes + else + gdb_cv_have_texi2dvi_build_opt=no + fi]) +if test x"$gdb_cv_have_texi2dvi_build_opt" = xyes; then + TEXI2DVI_EXTRA_FLAGS="$TEXI2DVI_EXTRA_FLAGS --build=tidy" +fi +AC_SUBST(TEXI2DVI_EXTRA_FLAGS) + GDB_AC_WITH_DIR(DEBUGDIR, separate-debug-dir, [look for global separate debug info in this path @<:@LIBDIR/debug@:>@], [${libdir}/debug]) diff --git a/gdb/doc/Makefile.in b/gdb/doc/Makefile.in index 3d64526f542..cdb046bd90f 100644 --- a/gdb/doc/Makefile.in +++ b/gdb/doc/Makefile.in @@ -68,6 +68,8 @@ TEXI2ROFF=texi2roff # where to find texi2dvi, ditto TEXI2DVI=texi2dvi +TEXI2DVI_EXTRA_FLAGS=@TEXI2DVI_EXTRA_FLAGS@ +TEXI2DVI_CMD = $(TEXI2DVI) $(TEXI2DVI_EXTRA_FLAGS) # Package to install the docs under PACKAGE = @PACKAGE@ @@ -492,21 +494,26 @@ gdb-cfg.texi: ${srcdir}/${DOC_CONFIG}-cfg.texi # Clean these up before each run. Avoids a catch 22 with not being # able to re-generate these files (to fix a corruption) because these # files contain a corruption. +# +# If TEXI2DVI_CMD includes the --build option then these files should +# not be created in the current directory, but attempting to delete +# them is harmless. GDB_TEX_TMPS = gdb.aux gdb.cp* gdb.fn* gdb.ky* gdb.log gdb.pg* gdb.toc \ gdb.tp* gdb.vr* # GDB MANUAL: TeX dvi file gdb.dvi: ${GDB_DOC_FILES} - $(SILENCE) rm -f $(GDB_TEX_TMPS) - $(ECHO_TEXI2DVI) $(TEXI2DVI) $(SILENT_Q_FLAG) $(READLINE_TEXI_INCFLAG) \ - -I ${GDBMI_DIR} -I $(srcdir) $(srcdir)/gdb.texinfo + $(SILENCE) rm -fr $(GDB_TEX_TMPS) gdb.t2d/dvi/ + $(ECHO_TEXI2DVI) $(TEXI2DVI_CMD) $(SILENT_Q_FLAG) \ + $(READLINE_TEXI_INCFLAG) -I ${GDBMI_DIR} -I $(srcdir) \ + $(srcdir)/gdb.texinfo gdb.ps: gdb.dvi $(ECHO_DVIPS) $(DVIPS) $(SILENT_Q_FLAG) -o $@ $? gdb.pdf: ${GDB_DOC_FILES} - $(SILENCE) rm -f $(GDB_TEX_TMPS) - $(ECHO_TEXI2DVI) $(TEXI2DVI) $(SILENT_Q_FLAG) --pdf \ + $(SILENCE) rm -fr $(GDB_TEX_TMPS) gdb.t2d/pdf/ + $(ECHO_TEXI2DVI) $(TEXI2DVI_CMD) $(SILENT_Q_FLAG) --pdf \ $(READLINE_TEXI_INCFLAG) -I ${GDBMI_DIR} -I $(srcdir) \ $(srcdir)/gdb.texinfo @@ -607,41 +614,49 @@ stabs/index.html: $(STABS_DOC_FILES) # Clean these up before each run. Avoids a catch 22 with not being # able to re-generate these files (to fix a corruption) because these # files contain a corruption. +# +# If TEXI2DVI_CMD includes the --build option then these files should +# not be created in the current directory, but attempting to delete +# them is harmless. STABS_TEX_TMPS = stabs.aux stabs.cp* stabs.fn* stabs.ky* \ stabs.log stabs.pg* stabs.toc stabs.tp* stabs.vr* # STABS DOCUMENTATION: TeX dvi file stabs.dvi : $(STABS_DOC_FILES) - $(SILENCE) rm -f $(STABS_TEX_TMPS) - $(ECHO_TEXI2DVI) $(TEXI2DVI) $(SILENT_Q_FLAG) -I $(srcdir) \ + $(SILENCE) rm -fr $(STABS_TEX_TMPS) stabs.t2d/dvi/ + $(ECHO_TEXI2DVI) $(TEXI2DVI_CMD) $(SILENT_Q_FLAG) -I $(srcdir) \ $(srcdir)/stabs.texinfo stabs.ps: stabs.dvi $(ECHO_DVIPS) $(DVIPS) $(SILENT_Q_FLAG) -o $@ $? stabs.pdf: $(STABS_DOC_FILES) - $(SILENCE) rm -f $(STABS_TEX_TMPS) - $(ECHO_TEXI2DVI) $(TEXI2DVI) $(SILENT_Q_FLAG) --pdf -I $(srcdir) \ + $(SILENCE) rm -fr $(STABS_TEX_TMPS) stabs.t2d/pdf/ + $(ECHO_TEXI2DVI) $(TEXI2DVI_CMD) $(SILENT_Q_FLAG) --pdf -I $(srcdir) \ $(srcdir)/stabs.texinfo # Clean these up before each run. Avoids a catch 22 with not being # able to re-generate these files (to fix a corruption) because these # files contain a corruption. +# +# If TEXI2DVI_CMD includes the --build option then these files should +# not be created in the current directory, but attempting to delete +# them is harmless. ANNOTATE_TEX_TMPS = annotate.aux annotate.cp* annotate.fn* annotate.ky* \ annotate.log annotate.pg* annotate.toc annotate.tp* annotate.vr* # ANNOTATE DOCUMENTATION: TeX dvi file annotate.dvi : $(ANNOTATE_DOC_FILES) - $(SILENCE) rm -f $(ANNOTATE_TEX_TMPS) - $(ECHO_TEXI2DVI) $(TEXI2DVI) $(SILENT_Q_FLAG) -I $(srcdir) \ + $(SILENCE) rm -fr $(ANNOTATE_TEX_TMPS) annotate.t2d/dvi/ + $(ECHO_TEXI2DVI) $(TEXI2DVI_CMD) $(SILENT_Q_FLAG) -I $(srcdir) \ $(srcdir)/annotate.texinfo annotate.ps: annotate.dvi $(ECHO_DVIPS) $(DVIPS) $(SILENT_Q_FLAG) -o $@ $? annotate.pdf: $(ANNOTATE_DOC_FILES) - $(SILENCE) rm -f $(ANNOTATE_TEX_TMPS) - $(ECHO_TEXI2DVI) $(TEXI2DVI) $(SILENT_Q_FLAG) --pdf -I $(srcdir) \ + $(SILENCE) rm -fr $(ANNOTATE_TEX_TMPS) annotate.t2d/pdf/ + $(ECHO_TEXI2DVI) $(TEXI2DVI_CMD) $(SILENT_Q_FLAG) --pdf -I $(srcdir) \ $(srcdir)/annotate.texinfo annotate.info: $(ANNOTATE_DOC_FILES) @@ -689,6 +704,7 @@ Makefile: Makefile.in $(host_makefile_frag) ../config.status mostlyclean: rm -f gdb.mm gdb.ms gdb.me links2roff + rm -fr annotate.t2d/ stabs.t2d/ gdb.t2d/ rm -f $(GDB_TEX_TMPS) rm -f $(STABS_TEX_TMPS) rm -f $(ANNOTATE_TEX_TMPS) -- 2.25.4 ^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCHv3 0/6] gdb/doc: parallel build fixes and improvements 2024-05-31 8:18 ` [PATCHv2 0/5] gdb/doc: parallel build fixes and improvements Andrew Burgess ` (4 preceding siblings ...) 2024-05-31 8:18 ` [PATCHv2 5/5] gdb/doc: fix parallel build of pdf and dvi files Andrew Burgess @ 2024-06-06 17:49 ` Andrew Burgess 2024-06-06 17:49 ` [PATCHv3 1/6] gdb/doc: don't try to copy GDBvn.texi from the source tree Andrew Burgess ` (6 more replies) 5 siblings, 7 replies; 42+ messages in thread From: Andrew Burgess @ 2024-06-06 17:49 UTC (permalink / raw) To: gdb-patches; +Cc: Andrew Burgess In v3: - Add new patch #2 which merges the two man page rules into one. - Updated patch #3 based on Eli's feedback. Now use $< instead of a shell snippet to locate version.subst. In V2: - Patch #1: the content of this patch is unchanged from v1, however the commit message is completely rewritten. I believe the change I made was good, but my previous justification was completely wrong! - Patches #2 and #3: these patches are completely new in v2. - Patches #4 and #5: these are completely unchanged from v1 where they were already approved. Further feedback is of course welcome, but if you want to skip looking at these, that's fine too. Thanks, Andrew --- Andrew Burgess (6): gdb/doc: don't try to copy GDBvn.texi from the source tree gdb/doc: merge rules for building .1 and .5 man pages gdb/doc: allow for version.subst in the source tree gdb/doc: also look in srcdir when running TEXI2POD gdb/doc: fix parallel build of refcard related targets gdb/doc: fix parallel build of pdf and dvi files gdb/configure | 33 ++++++++++- gdb/configure.ac | 21 +++++++ gdb/doc/Makefile.in | 135 +++++++++++++++++++++++--------------------- 3 files changed, 122 insertions(+), 67 deletions(-) base-commit: de4edfcb949c0d04ec8b49fdfe06267f92618589 -- 2.25.4 ^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCHv3 1/6] gdb/doc: don't try to copy GDBvn.texi from the source tree 2024-06-06 17:49 ` [PATCHv3 0/6] gdb/doc: parallel build fixes and improvements Andrew Burgess @ 2024-06-06 17:49 ` Andrew Burgess 2024-06-14 18:45 ` Pedro Alves 2024-06-06 17:49 ` [PATCHv3 2/6] gdb/doc: merge rules for building .1 and .5 man pages Andrew Burgess ` (5 subsequent siblings) 6 siblings, 1 reply; 42+ messages in thread From: Andrew Burgess @ 2024-06-06 17:49 UTC (permalink / raw) To: gdb-patches; +Cc: Andrew Burgess The build recipe for gdb.dvi and gdb.pdf contains instructions for copying the GDBvn.texi file from the source tree into the build directory if the GDBvn.texi file doesn't already exist in the build directory. The gdb.dvi and gdb.pdf targets also have a dependency on GDBvn.texi, and we have a recipe for building GDBvn.texi. What's happening here is this: - In a git checkout of the source tree there is no GDBvn.texi in the source tree, the GDBvn.texi dependency will trigger a rebuild of GDBvn.texi, which is then used to build gdb.dvi and/or gdb.pdf. - In a release tar file we do include a copy of GDBvn.texi. This file will appear to be up to date, and so no copy of GDBvn.texi is created within the build directory. Now when building gdb.dvi and/or gdb.pdf we copy (or symlink) the version of GDBvn.texi from the source tree into the build directory. However, copying GDBvn.texi into the source directory is completely unnecessary. The gdb.dvi/gdb.pdf recipes both invoke texi2dvi and pass '-I $(srcdir)' as an argument, this means that texi2dvi will look in the $(srcdir) to find included files, including GDBvn.texi. As such I believe we can remove the code that copies GDBvn.texi from the source tree into the build tree. I've tested with a release build; creating a release with: ./src-release gdb Then in an empty directory, unpacking the resulting .tar file, creating a parallel build directory and doing the usual configure, make, and 'make install'. Having done this I can then 'touch gdb/doc/*.texinfo' in the unpacked source tree, and do 'make -C gdb/doc pdf dvi' to rebuild all the pdf and dvi files, this works fine without having to either build or copy GDBvn.texi into the build directory. --- gdb/doc/Makefile.in | 17 ----------------- 1 file changed, 17 deletions(-) diff --git a/gdb/doc/Makefile.in b/gdb/doc/Makefile.in index d9c13873a60..1a0791d518f 100644 --- a/gdb/doc/Makefile.in +++ b/gdb/doc/Makefile.in @@ -477,15 +477,6 @@ gdb-cfg.texi: ${srcdir}/${DOC_CONFIG}-cfg.texi ln ${srcdir}/${DOC_CONFIG}-cfg.texi gdb-cfg.texi || \ cp ${srcdir}/${DOC_CONFIG}-cfg.texi gdb-cfg.texi -# GDB MANUAL: texinfo source, using @set/@clear/@value/@ifset/@ifclear -# If your texinfo or makeinfo don't support these, get a new texinfo release -# -# The nonsense with GDBvn.texi gets this to run with both Sun and GNU make. -# Note that we can *generate* GDBvn.texi, but since we distribute one in the -# source directory for the benefit of people who *don't* use this makefile, -# VPATH will often tell make not to bother building it, because the one -# in the srcdir is up to date. (if not, then make should build one here). - # Clean these up before each run. Avoids a catch 22 with not being # able to re-generate these files (to fix a corruption) because these # files contain a corruption. @@ -494,10 +485,6 @@ GDB_TEX_TMPS = gdb.aux gdb.cp* gdb.fn* gdb.ky* gdb.log gdb.pg* gdb.toc \ # GDB MANUAL: TeX dvi file gdb.dvi: ${GDB_DOC_FILES} - $(SILENCE) if [ ! -f ./GDBvn.texi ]; then \ - (test "$(LN_S)" = "ln -s" && ln -s $(srcdir)/GDBvn.texi .) || \ - ln $(srcdir)/GDBvn.texi . || \ - cp $(srcdir)/GDBvn.texi . ; else true; fi $(SILENCE) rm -f $(GDB_TEX_TMPS) $(ECHO_TEXI2DVI) $(TEXI2DVI) $(SILENT_Q_FLAG) $(READLINE_TEXI_INCFLAG) \ -I ${GDBMI_DIR} -I $(srcdir) $(srcdir)/gdb.texinfo @@ -506,10 +493,6 @@ gdb.ps: gdb.dvi $(ECHO_DVIPS) $(DVIPS) $(SILENT_Q_FLAG) -o $@ $? gdb.pdf: ${GDB_DOC_FILES} - $(SILENCE) if [ ! -f ./GDBvn.texi ]; then \ - (test "$(LN_S)" = "ln -s" && ln -s $(srcdir)/GDBvn.texi .) || \ - ln $(srcdir)/GDBvn.texi . || \ - cp $(srcdir)/GDBvn.texi . ; else true; fi $(SILENCE) rm -f $(GDB_TEX_TMPS) $(ECHO_TEXI2DVI) $(TEXI2DVI) $(SILENT_Q_FLAG) --pdf \ $(READLINE_TEXI_INCFLAG) -I ${GDBMI_DIR} -I $(srcdir) \ -- 2.25.4 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCHv3 1/6] gdb/doc: don't try to copy GDBvn.texi from the source tree 2024-06-06 17:49 ` [PATCHv3 1/6] gdb/doc: don't try to copy GDBvn.texi from the source tree Andrew Burgess @ 2024-06-14 18:45 ` Pedro Alves 0 siblings, 0 replies; 42+ messages in thread From: Pedro Alves @ 2024-06-14 18:45 UTC (permalink / raw) To: Andrew Burgess, gdb-patches On 2024-06-06 18:49, Andrew Burgess wrote: > However, copying GDBvn.texi into the source directory is completely > unnecessary. I think you meant "from the source directory" here. ^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCHv3 2/6] gdb/doc: merge rules for building .1 and .5 man pages 2024-06-06 17:49 ` [PATCHv3 0/6] gdb/doc: parallel build fixes and improvements Andrew Burgess 2024-06-06 17:49 ` [PATCHv3 1/6] gdb/doc: don't try to copy GDBvn.texi from the source tree Andrew Burgess @ 2024-06-06 17:49 ` Andrew Burgess 2024-06-06 17:49 ` [PATCHv3 3/6] gdb/doc: allow for version.subst in the source tree Andrew Burgess ` (4 subsequent siblings) 6 siblings, 0 replies; 42+ messages in thread From: Andrew Burgess @ 2024-06-06 17:49 UTC (permalink / raw) To: gdb-patches; +Cc: Andrew Burgess We have two rules, one each for building the .1 and .5 man pages. The only actual difference is that one rule passes --section=1 and the other passes --section=5 (see the definitions of POD2MAN1 and POD2MAN5 respectively. I figure by using the suffix from the target of the rule we can combine these two rules into one. I use: $(subst .,,$(suffix $@)) This gets the suffix from the target, either '.1' or '.5', and the 'subst' removes the '.' leaving '1' or '5'. Now that I'm not using a static pattern rule for building the man pages, the advice in the 'make' documentation is to not use $*, so I've moved away from that to instead use $(basename $@), e.g. for 'gdbinit.5' this gives 'gdbinit', which is what we want. There should be no difference in what is created after this change. --- gdb/doc/Makefile.in | 23 +++++++++-------------- 1 file changed, 9 insertions(+), 14 deletions(-) diff --git a/gdb/doc/Makefile.in b/gdb/doc/Makefile.in index 1a0791d518f..70d65d58ed0 100644 --- a/gdb/doc/Makefile.in +++ b/gdb/doc/Makefile.in @@ -178,10 +178,8 @@ MANCONF = -Dman TEXI2POD = perl $(srcdir)/../../etc/texi2pod.pl \ $(MAKEINFOFLAGS) $(MAKEINFO_EXTRA_FLAGS) -POD2MAN1 = pod2man --center="GNU Development Tools" \ - --release="gdb-`sed q version.subst`" --section=1 -POD2MAN5 = pod2man --center="GNU Development Tools" \ - --release="gdb-`sed q version.subst`" --section=5 +POD2MAN = pod2man --center="GNU Development Tools" \ + --release="gdb-`sed q version.subst`" # List of man pages generated from gdb.texi MAN1S = gdb.1 gdbserver.1 gcore.1 gdb-add-index.1 @@ -654,17 +652,14 @@ annotate/index.html: $(ANNOTATE_DOC_FILES) # pages, then the .pod files must become a dependency, this will # trigger an attempt to rebuild these files while building and # installing a release of GDB, which is something we don't want. -$(MAN1S) : %.1 : $(GDB_DOC_FILES) - $(ECHO_TEXI2POD) $(TEXI2POD) $(MANCONF) -D$* < $(srcdir)/gdb.texinfo > $*.pod - $(ECHO_TEXI2MAN) ($(POD2MAN1) $*.pod | sed -e '/^.if n .na/d' > $@.T$$$$ && \ +$(MAN1S) $(MAN5S) : version.subst $(GDB_DOC_FILES) + $(ECHO_TEXI2POD) $(TEXI2POD) $(MANCONF) -D$(basename $@) \ + < $(srcdir)/gdb.texinfo > $(basename $@).pod + $(ECHO_TEXI2MAN) ($(POD2MAN) --section=$(subst .,,$(suffix $@)) \ + $(basename $@).pod | \ + sed -e '/^.if n .na/d' > $@.T$$$$ && \ mv -f $@.T$$$$ $@) || (rm -f $@.T$$$$ && exit 1) - $(SILENCE) rm -f $*.pod - -$(MAN5S) : %.5 : $(GDB_DOC_FILES) - $(ECHO_TEXI2POD) $(TEXI2POD) $(MANCONF) -D$* < $(srcdir)/gdb.texinfo > $*.pod - $(ECHO_TEXI2MAN) ($(POD2MAN5) $*.pod | sed -e '/^.if n .na/d' > $@.T$$$$ && \ - mv -f $@.T$$$$ $@) || (rm -f $@.T$$$$ && exit 1) - $(SILENCE) rm -f $*.pod + $(SILENCE) rm -f $(basename $@).pod force: -- 2.25.4 ^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCHv3 3/6] gdb/doc: allow for version.subst in the source tree 2024-06-06 17:49 ` [PATCHv3 0/6] gdb/doc: parallel build fixes and improvements Andrew Burgess 2024-06-06 17:49 ` [PATCHv3 1/6] gdb/doc: don't try to copy GDBvn.texi from the source tree Andrew Burgess 2024-06-06 17:49 ` [PATCHv3 2/6] gdb/doc: merge rules for building .1 and .5 man pages Andrew Burgess @ 2024-06-06 17:49 ` Andrew Burgess 2024-06-14 18:44 ` Pedro Alves 2024-06-06 17:49 ` [PATCHv3 4/6] gdb/doc: also look in srcdir when running TEXI2POD Andrew Burgess ` (3 subsequent siblings) 6 siblings, 1 reply; 42+ messages in thread From: Andrew Burgess @ 2024-06-06 17:49 UTC (permalink / raw) To: gdb-patches; +Cc: Andrew Burgess In a git checkout of the source code we don't have a version.subst file in the gdb/doc directory. When building the GDB docs the version.subst file is generated on demand (we have a recipe for that). However, in a release tar file we do include a copy of the version.subst file in the source tree, as a result the version.subst recipe will not be run. If, in a release build, we force the running of any recipe that depends on version.subst then we run into a problem. For example, slightly confusingly, if we 'touch gdb/doc/version.subst' within the unpacked source tree of a release, then 'make -C gdb/doc GDBvn.texi' in the build tree, we'll see: make: Entering directory '/tmp/build/build/gdb/doc' GEN GDBvn.texi sed: can't read version.subst: No such file or directory make: Leaving directory '/tmp/build/build/gdb/doc' The problem is that every reference to version.subst in GDB's Makefile assumes that the version.subst file will always be in the build directory. Handily version.subst is always the first dependency in every recipe that uses that file. As such we can replace references to version.subst with $<, make will expand this to the location where the dependency was found. In the case of the man page generation, the reference to version.subst is hidden inside POD2MAN. It seemed a little confusing adding a use of $< within POD2MAN, so I've moved the use into the recipe, which I think is clearer. I've also added comments for the two rules that I've modified to explain our use of $<. After this change it is possible to rebuild the man pages even when version.subst is located in the source tree. --- gdb/doc/Makefile.in | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/gdb/doc/Makefile.in b/gdb/doc/Makefile.in index 70d65d58ed0..eb800bf3848 100644 --- a/gdb/doc/Makefile.in +++ b/gdb/doc/Makefile.in @@ -178,8 +178,8 @@ MANCONF = -Dman TEXI2POD = perl $(srcdir)/../../etc/texi2pod.pl \ $(MAKEINFOFLAGS) $(MAKEINFO_EXTRA_FLAGS) -POD2MAN = pod2man --center="GNU Development Tools" \ - --release="gdb-`sed q version.subst`" + +POD2MAN = pod2man --center="GNU Development Tools" # List of man pages generated from gdb.texi MAN1S = gdb.1 gdbserver.1 gcore.1 gdb-add-index.1 @@ -435,9 +435,14 @@ refcard.pdf : refcard.tex $(REFEDITS) $(SILENCE) rm -f sedref.log sedref.tex tmp.sed # File to record current GDB version number. +# +# It is important that version.subst be the first dependency so that +# $< can be used in the recipe, this allows us to find version.subst +# in either the source tree or the build tree as this file is +# included, pre-built, as part of a relase. GDBvn.texi : version.subst $(ECHO_GEN) - $(SILENCE) echo "@set GDBVN `sed q version.subst`" > ./GDBvn.new + $(SILENCE) echo "@set GDBVN `sed q $<`" > ./GDBvn.new $(SILENCE) if [ -n "$(PKGVERSION)" ]; then \ echo "@set VERSION_PACKAGE $(PKGVERSION)" >> ./GDBvn.new; \ fi @@ -652,11 +657,16 @@ annotate/index.html: $(ANNOTATE_DOC_FILES) # pages, then the .pod files must become a dependency, this will # trigger an attempt to rebuild these files while building and # installing a release of GDB, which is something we don't want. +# +# It is important that version.subst be the first dependency so that +# $< can be used in the recipe, this allows us to find version.subst +# in either the source tree or the build tree as this file is +# included, pre-built, as part of a relase. $(MAN1S) $(MAN5S) : version.subst $(GDB_DOC_FILES) $(ECHO_TEXI2POD) $(TEXI2POD) $(MANCONF) -D$(basename $@) \ < $(srcdir)/gdb.texinfo > $(basename $@).pod $(ECHO_TEXI2MAN) ($(POD2MAN) --section=$(subst .,,$(suffix $@)) \ - $(basename $@).pod | \ + --release="gdb-`sed q $<`" $(basename $@).pod | \ sed -e '/^.if n .na/d' > $@.T$$$$ && \ mv -f $@.T$$$$ $@) || (rm -f $@.T$$$$ && exit 1) $(SILENCE) rm -f $(basename $@).pod -- 2.25.4 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCHv3 3/6] gdb/doc: allow for version.subst in the source tree 2024-06-06 17:49 ` [PATCHv3 3/6] gdb/doc: allow for version.subst in the source tree Andrew Burgess @ 2024-06-14 18:44 ` Pedro Alves 0 siblings, 0 replies; 42+ messages in thread From: Pedro Alves @ 2024-06-14 18:44 UTC (permalink / raw) To: Andrew Burgess, gdb-patches Hi, I was skimming this and noticed a couple typos. On 2024-06-06 18:49, Andrew Burgess wrote: > +# included, pre-built, as part of a relase. relase -> release > +# included, pre-built, as part of a relase. Same. (Appears twice in the patch.) ^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCHv3 4/6] gdb/doc: also look in srcdir when running TEXI2POD 2024-06-06 17:49 ` [PATCHv3 0/6] gdb/doc: parallel build fixes and improvements Andrew Burgess ` (2 preceding siblings ...) 2024-06-06 17:49 ` [PATCHv3 3/6] gdb/doc: allow for version.subst in the source tree Andrew Burgess @ 2024-06-06 17:49 ` Andrew Burgess 2024-06-06 17:49 ` [PATCHv3 5/6] gdb/doc: fix parallel build of refcard related targets Andrew Burgess ` (2 subsequent siblings) 6 siblings, 0 replies; 42+ messages in thread From: Andrew Burgess @ 2024-06-06 17:49 UTC (permalink / raw) To: gdb-patches; +Cc: Andrew Burgess In gdb/doc/Makefile.in the TEXI2POD variable is used to invoke texi2pod.pl, which process the .texinfo files. This also handles the 'include' directives within the .texinfo files. Like the texi2dvi and texi2pdf tools, texi2pod.pl handles the -I flag to add search directories for resolving 'include' directives within .texinfo files. When GDB runs TEXI2POD we include gdb-cfg.texi, which then includes GDBvn.texi. When building from a git checkout the gdb-cfg.texi files and GDBvn.texi files will be created in the build directory, which is where texi2pod.pl is invoked, so the files will be found just fine. However, for a GDB release we ship gdb-cfg.texi and GDBvn.texi in the source tree, along with the generated manual (.1 and .5) files. So when building a release, what normally happens is that we spot that the .1 and .5 man files are up to date, and don't run the recipe to regenerate these files. However, if we deliberately touch the *.texinfo files in a release source tree, and then try to rebuild the man files, we'll get an error like this: make: Entering directory '/tmp/release-build/build/gdb/doc' TEXI2POD gdb.1 cannot find GDBvn.texi at ../../../gdb-16.0.50.20240529/gdb/doc/../../etc/texi2pod.pl line 251, <GEN0> line 16. make: *** [Makefile:664: gdb.1] Error 2 make: Leaving directory '/tmp/release-build/build/gdb/doc' The problem is that texi2pod.pl doesn't know to look in the source tree for the GDBvn.texi file. If we compare this to the recipe for creating (for example) gdb.dvi, which uses texi2dvi, this recipe adds '-I $(srcdir)' to the texi2dvi command line, which allows texi2dvi to find GDBvn.texi in the source tree. In this commit I add a similar -I option to the texi2pod.pl command line. After this, given a GDB release, it is possible to edit (or just touch) the gdb.texinfo file and rebuild the man pages, the GDBvn.texi will be picked up from the source tree. If however a dependency for GDBvn.texi is changed in a release tree then GDBvn.texi will be regenerated into the build directory and this will be picked up in preference to the GDBvn.texi in the source tree, just as you would want. --- gdb/doc/Makefile.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gdb/doc/Makefile.in b/gdb/doc/Makefile.in index eb800bf3848..7b7b85dae10 100644 --- a/gdb/doc/Makefile.in +++ b/gdb/doc/Makefile.in @@ -176,7 +176,7 @@ ANNOTATE_DOC_FILES = \ MANCONF = -Dman TEXI2POD = perl $(srcdir)/../../etc/texi2pod.pl \ - $(MAKEINFOFLAGS) $(MAKEINFO_EXTRA_FLAGS) + $(MAKEINFOFLAGS) $(MAKEINFO_EXTRA_FLAGS) -I $(srcdir) POD2MAN = pod2man --center="GNU Development Tools" -- 2.25.4 ^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCHv3 5/6] gdb/doc: fix parallel build of refcard related targets 2024-06-06 17:49 ` [PATCHv3 0/6] gdb/doc: parallel build fixes and improvements Andrew Burgess ` (3 preceding siblings ...) 2024-06-06 17:49 ` [PATCHv3 4/6] gdb/doc: also look in srcdir when running TEXI2POD Andrew Burgess @ 2024-06-06 17:49 ` Andrew Burgess 2024-06-06 17:49 ` [PATCHv3 6/6] gdb/doc: fix parallel build of pdf and dvi files Andrew Burgess 2024-06-14 18:14 ` [PATCHv3 0/6] gdb/doc: parallel build fixes and improvements Tom Tromey 6 siblings, 0 replies; 42+ messages in thread From: Andrew Burgess @ 2024-06-06 17:49 UTC (permalink / raw) To: gdb-patches; +Cc: Andrew Burgess, Tom Tromey There are two problems we encounter when trying to build the refcard related target in parallel, i.e.: $ make -j20 -C gdb/doc/ refcard.dvi refcard.ps refcard.pdf These problems are: (1) The refcard.dvi and refcard.pdf targets both try and generate the tmp.sed and sedref.tex files. If two make threads end up trying to create these files at the same time then the result is these files become corrupted. I've fixed this by creating a new rule that creates sedref.tex, both refcard.dvi and refcard.pdf now depend on this, and make will build sedref.tex just once. The tmp.sed file is now generated as refcard.sed, this is generated and deleted as a temporary file within the sedref.tex recipe. (2) Having created sedref.tex the recipes for refcard.dvi and refcard.pdf both run various LaTeX based tools with sedref.tex as the input file. The problem with this is that these tools all rely on creating temporary files calls sedref.*. If the refcard.dvi and refcard.pdf rules run at the same time then these temporary files clash and overwrite each other causing the build to fail. We already copy the result file in order to rename it, our input file is sedref.tex which results in an output file named sedref.dvi or sedref.pdf, but we actually want refcard.dvi or refcard.pdf. So within the recipe for refcard.dvi I copy the input file from sedref.tex to sedref_dvi.tex. Now all the temp files are named sedref_dvi.* and the output is sedref_dvi.dvi, I then rename this new output file to refcard.dvi. I've done the same thing for refcard.pdf, but I copy the input to sedref_pdf.tex. In this way the temp files no longer clash, and both recipes can safely run in parallel. After this commit I was able to reliably build all of the refcard targets in parallel. There should be no change in the final file. Approved-By: Tom Tromey <tom@tromey.com> --- gdb/doc/Makefile.in | 39 ++++++++++++++++++++------------------- 1 file changed, 20 insertions(+), 19 deletions(-) diff --git a/gdb/doc/Makefile.in b/gdb/doc/Makefile.in index 7b7b85dae10..d294120ad19 100644 --- a/gdb/doc/Makefile.in +++ b/gdb/doc/Makefile.in @@ -408,31 +408,32 @@ de-stage3: force -(cd stage3 ; mv -f * ..) -rmdir stage3 -# GDB QUICK REFERENCE (dvi output) -refcard.dvi : refcard.tex $(REFEDITS) - $(SILENCE) echo > tmp.sed + +sedref.tex : refcard.tex $(REFEDITS) + $(SILENCE) echo > refcard.sed $(SILENCE) for f in x $(REFEDITS) ; do \ test x$$f = xx && continue ; \ - cat $(srcdir)/$$f >>tmp.sed ; \ + cat $(srcdir)/$$f >>refcard.sed ; \ done - $(SILENCE) sed -f tmp.sed $(srcdir)/refcard.tex >sedref.tex - $(ECHO_TEX) $(SET_TEXINPUTS) $(TEX) sedref.tex - $(SILENCE) mv sedref.dvi refcard.dvi - $(SILENCE) rm -f sedref.log sedref.tex tmp.sed + $(ECHO_GEN) sed -f refcard.sed $(srcdir)/refcard.tex >$@ + $(SILENCE) rm -f refcard.sed + + +# GDB QUICK REFERENCE (dvi output) +refcard.dvi : sedref.tex + $(SILENCE) rm -f sedref_dvi.* + $(SILENCE) cp $< sedref_dvi.tex + $(ECHO_TEX) $(SET_TEXINPUTS) $(TEX) sedref_dvi.tex && \ + mv sedref_dvi.dvi $@ refcard.ps : refcard.dvi $(ECHO_DVIPS) $(DVIPS) $(SILENT_Q_FLAG) -t landscape -o $@ $? -refcard.pdf : refcard.tex $(REFEDITS) - $(SILENCE) echo > tmp.sed - $(SILENCE) for f in x $(REFEDITS) ; do \ - test x$$f = xx && continue ; \ - cat $(srcdir)/$$f >>tmp.sed ; \ - done - $(SILENCE) sed -f tmp.sed $(srcdir)/refcard.tex >sedref.tex - $(ECHO_PDFTEX) $(SET_TEXINPUTS) $(PDFTEX) sedref.tex - $(SILENCE) mv sedref.pdf refcard.pdf - $(SILENCE) rm -f sedref.log sedref.tex tmp.sed +refcard.pdf : sedref.tex + $(SILENCE) rm -f sedref_pdf.* + $(SILENCE) cp $< sedref_pdf.tex + $(ECHO_PDFTEX) $(SET_TEXINPUTS) $(PDFTEX) sedref_pdf.tex && \ + mv sedref_pdf.pdf $@ # File to record current GDB version number. # @@ -685,7 +686,7 @@ mostlyclean: rm -f $(GDB_TEX_TMPS) rm -f $(STABS_TEX_TMPS) rm -f $(ANNOTATE_TEX_TMPS) - rm -f sedref.dvi sedref.tex tmp.sed sedref.log + rm -f refcard.sed sedref.tex sedref_dvi.* sedref_pdf.* rm -f $(POD_FILE_TMPS) clean: mostlyclean -- 2.25.4 ^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCHv3 6/6] gdb/doc: fix parallel build of pdf and dvi files 2024-06-06 17:49 ` [PATCHv3 0/6] gdb/doc: parallel build fixes and improvements Andrew Burgess ` (4 preceding siblings ...) 2024-06-06 17:49 ` [PATCHv3 5/6] gdb/doc: fix parallel build of refcard related targets Andrew Burgess @ 2024-06-06 17:49 ` Andrew Burgess 2024-06-14 19:00 ` Pedro Alves 2024-06-14 18:14 ` [PATCHv3 0/6] gdb/doc: parallel build fixes and improvements Tom Tromey 6 siblings, 1 reply; 42+ messages in thread From: Andrew Burgess @ 2024-06-06 17:49 UTC (permalink / raw) To: gdb-patches; +Cc: Andrew Burgess, Tom Tromey When building with 'make -j20 -C gdb/doc all-doc' I often see problems caused from trying to build some dvi files in parallel with some pdf files. The problem files are: gdb.dvi and gdb.pdf; stabs.dvi and stabs.pdf; and annotate.dvi and annotate.pdf. The problem is that building these files create temporary files in the local directory. There's already a race here that two make threads might try to create these files at the same time. But it gets worse, to avoid issues where a failed build could leave these temporary files in a corrupted state, and so prevent the next build from succeeding, the recipe for each of these files delete all the temporary files first, this obviously causes problems if some other thread has already started the build and is relying on these temporary files. To work around this problem I propose we start using the --build flag for texi2dvi (which is the same tool used to create the pdf files). The --build flag allows for the temporary files to be placed into a sub-directory, e.g. creating gdb.pdf will create the temporary files in gdb.t2d/pdf/ and gdb.dvi uses gdb.t2d/dvi/, in this way the temporary files will never clash, and we can easily delete the specific sub-directory at the start of the recipe to ensure a successful build. Very old versions of texi2dvi don't support --build, so I've added a configure check for this option. If the option is not supported then we don't use it. This means we fall back to placing temporary files in the local directory, which means parallel builds will remain broken. The --build option is definitely present in texi2dvi version 6.1, from 2016, so any version after that should be fine. For me, with this fix in place, I can now run 'make -j20 -C gdb/doc all-doc' without seeing any build problems. Approved-By: Tom Tromey <tom@tromey.com> --- gdb/configure | 33 +++++++++++++++++++++++++++++++-- gdb/configure.ac | 21 +++++++++++++++++++++ gdb/doc/Makefile.in | 42 +++++++++++++++++++++++++++++------------- 3 files changed, 81 insertions(+), 15 deletions(-) diff --git a/gdb/configure b/gdb/configure index 66a7ad8d256..8d870d50de3 100755 --- a/gdb/configure +++ b/gdb/configure @@ -765,6 +765,7 @@ ENABLE_BFD_64_BIT_TRUE subdirs GDB_DATADIR DEBUGDIR +TEXI2DVI_EXTRA_FLAGS MAKEINFO_EXTRA_FLAGS MAKEINFOFLAGS MAKEINFO @@ -11499,7 +11500,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 11502 "configure" +#line 11503 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -11605,7 +11606,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 11608 "configure" +#line 11609 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -24609,6 +24610,34 @@ if test x"$gdb_cv_have_makeinfo_click" = xyes; then fi +## Figure out if texi2dvi supports the --build option. Older versions +## didn't. If this option is not supported then parallel building in +## the docs/ directory is probably going to be broken. But single +## threaded build should be fine. +TEXI2DVI=texi2dvi +TEXI2DVI_EXTRA_FLAGS="" +{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $TEXI2DVI supports --build" >&5 +$as_echo_n "checking whether $TEXI2DVI supports --build... " >&6; } +if ${gdb_cv_have_texi2dvi_build_opt+:} false; then : + $as_echo_n "(cached) " >&6 +else + echo '\input texinfo' >conftest.texi + echo 'abc' >>conftest.texi + echo '@bye' >>conftest.texi + cp conftest.texi /home/andrew/tmp/ + if eval "$TEXI2DVI --build=tidy conftest.texi >&5 2>&5"; then + gdb_cv_have_texi2dvi_build_opt=yes + else + gdb_cv_have_texi2dvi_build_opt=no + fi +fi +{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $gdb_cv_have_texi2dvi_build_opt" >&5 +$as_echo "$gdb_cv_have_texi2dvi_build_opt" >&6; } +if test x"$gdb_cv_have_texi2dvi_build_opt" = xyes; then + TEXI2DVI_EXTRA_FLAGS="$TEXI2DVI_EXTRA_FLAGS --build=tidy" +fi + + # Check whether --with-separate-debug-dir was given. diff --git a/gdb/configure.ac b/gdb/configure.ac index 62ff09cea20..3b726e5f0aa 100644 --- a/gdb/configure.ac +++ b/gdb/configure.ac @@ -117,6 +117,27 @@ if test x"$gdb_cv_have_makeinfo_click" = xyes; then fi AC_SUBST(MAKEINFO_EXTRA_FLAGS) +## Figure out if texi2dvi supports the --build option. Older versions +## didn't. If this option is not supported then parallel building in +## the docs/ directory is probably going to be broken. But single +## threaded build should be fine. +TEXI2DVI=texi2dvi +TEXI2DVI_EXTRA_FLAGS="" +AC_CACHE_CHECK([whether $TEXI2DVI supports --build], gdb_cv_have_texi2dvi_build_opt, + [echo '\input texinfo' >conftest.texi + echo 'abc' >>conftest.texi + echo '@bye' >>conftest.texi + cp conftest.texi /home/andrew/tmp/ + if eval "$TEXI2DVI --build=tidy conftest.texi >&5 2>&5"; then + gdb_cv_have_texi2dvi_build_opt=yes + else + gdb_cv_have_texi2dvi_build_opt=no + fi]) +if test x"$gdb_cv_have_texi2dvi_build_opt" = xyes; then + TEXI2DVI_EXTRA_FLAGS="$TEXI2DVI_EXTRA_FLAGS --build=tidy" +fi +AC_SUBST(TEXI2DVI_EXTRA_FLAGS) + GDB_AC_WITH_DIR(DEBUGDIR, separate-debug-dir, [look for global separate debug info in this path @<:@LIBDIR/debug@:>@], [${libdir}/debug]) diff --git a/gdb/doc/Makefile.in b/gdb/doc/Makefile.in index d294120ad19..33149749982 100644 --- a/gdb/doc/Makefile.in +++ b/gdb/doc/Makefile.in @@ -68,6 +68,8 @@ TEXI2ROFF=texi2roff # where to find texi2dvi, ditto TEXI2DVI=texi2dvi +TEXI2DVI_EXTRA_FLAGS=@TEXI2DVI_EXTRA_FLAGS@ +TEXI2DVI_CMD = $(TEXI2DVI) $(TEXI2DVI_EXTRA_FLAGS) # Package to install the docs under PACKAGE = @PACKAGE@ @@ -484,21 +486,26 @@ gdb-cfg.texi: ${srcdir}/${DOC_CONFIG}-cfg.texi # Clean these up before each run. Avoids a catch 22 with not being # able to re-generate these files (to fix a corruption) because these # files contain a corruption. +# +# If TEXI2DVI_CMD includes the --build option then these files should +# not be created in the current directory, but attempting to delete +# them is harmless. GDB_TEX_TMPS = gdb.aux gdb.cp* gdb.fn* gdb.ky* gdb.log gdb.pg* gdb.toc \ gdb.tp* gdb.vr* # GDB MANUAL: TeX dvi file gdb.dvi: ${GDB_DOC_FILES} - $(SILENCE) rm -f $(GDB_TEX_TMPS) - $(ECHO_TEXI2DVI) $(TEXI2DVI) $(SILENT_Q_FLAG) $(READLINE_TEXI_INCFLAG) \ - -I ${GDBMI_DIR} -I $(srcdir) $(srcdir)/gdb.texinfo + $(SILENCE) rm -fr $(GDB_TEX_TMPS) gdb.t2d/dvi/ + $(ECHO_TEXI2DVI) $(TEXI2DVI_CMD) $(SILENT_Q_FLAG) \ + $(READLINE_TEXI_INCFLAG) -I ${GDBMI_DIR} -I $(srcdir) \ + $(srcdir)/gdb.texinfo gdb.ps: gdb.dvi $(ECHO_DVIPS) $(DVIPS) $(SILENT_Q_FLAG) -o $@ $? gdb.pdf: ${GDB_DOC_FILES} - $(SILENCE) rm -f $(GDB_TEX_TMPS) - $(ECHO_TEXI2DVI) $(TEXI2DVI) $(SILENT_Q_FLAG) --pdf \ + $(SILENCE) rm -fr $(GDB_TEX_TMPS) gdb.t2d/pdf/ + $(ECHO_TEXI2DVI) $(TEXI2DVI_CMD) $(SILENT_Q_FLAG) --pdf \ $(READLINE_TEXI_INCFLAG) -I ${GDBMI_DIR} -I $(srcdir) \ $(srcdir)/gdb.texinfo @@ -599,41 +606,49 @@ stabs/index.html: $(STABS_DOC_FILES) # Clean these up before each run. Avoids a catch 22 with not being # able to re-generate these files (to fix a corruption) because these # files contain a corruption. +# +# If TEXI2DVI_CMD includes the --build option then these files should +# not be created in the current directory, but attempting to delete +# them is harmless. STABS_TEX_TMPS = stabs.aux stabs.cp* stabs.fn* stabs.ky* \ stabs.log stabs.pg* stabs.toc stabs.tp* stabs.vr* # STABS DOCUMENTATION: TeX dvi file stabs.dvi : $(STABS_DOC_FILES) - $(SILENCE) rm -f $(STABS_TEX_TMPS) - $(ECHO_TEXI2DVI) $(TEXI2DVI) $(SILENT_Q_FLAG) -I $(srcdir) \ + $(SILENCE) rm -fr $(STABS_TEX_TMPS) stabs.t2d/dvi/ + $(ECHO_TEXI2DVI) $(TEXI2DVI_CMD) $(SILENT_Q_FLAG) -I $(srcdir) \ $(srcdir)/stabs.texinfo stabs.ps: stabs.dvi $(ECHO_DVIPS) $(DVIPS) $(SILENT_Q_FLAG) -o $@ $? stabs.pdf: $(STABS_DOC_FILES) - $(SILENCE) rm -f $(STABS_TEX_TMPS) - $(ECHO_TEXI2DVI) $(TEXI2DVI) $(SILENT_Q_FLAG) --pdf -I $(srcdir) \ + $(SILENCE) rm -fr $(STABS_TEX_TMPS) stabs.t2d/pdf/ + $(ECHO_TEXI2DVI) $(TEXI2DVI_CMD) $(SILENT_Q_FLAG) --pdf -I $(srcdir) \ $(srcdir)/stabs.texinfo # Clean these up before each run. Avoids a catch 22 with not being # able to re-generate these files (to fix a corruption) because these # files contain a corruption. +# +# If TEXI2DVI_CMD includes the --build option then these files should +# not be created in the current directory, but attempting to delete +# them is harmless. ANNOTATE_TEX_TMPS = annotate.aux annotate.cp* annotate.fn* annotate.ky* \ annotate.log annotate.pg* annotate.toc annotate.tp* annotate.vr* # ANNOTATE DOCUMENTATION: TeX dvi file annotate.dvi : $(ANNOTATE_DOC_FILES) - $(SILENCE) rm -f $(ANNOTATE_TEX_TMPS) - $(ECHO_TEXI2DVI) $(TEXI2DVI) $(SILENT_Q_FLAG) -I $(srcdir) \ + $(SILENCE) rm -fr $(ANNOTATE_TEX_TMPS) annotate.t2d/dvi/ + $(ECHO_TEXI2DVI) $(TEXI2DVI_CMD) $(SILENT_Q_FLAG) -I $(srcdir) \ $(srcdir)/annotate.texinfo annotate.ps: annotate.dvi $(ECHO_DVIPS) $(DVIPS) $(SILENT_Q_FLAG) -o $@ $? annotate.pdf: $(ANNOTATE_DOC_FILES) - $(SILENCE) rm -f $(ANNOTATE_TEX_TMPS) - $(ECHO_TEXI2DVI) $(TEXI2DVI) $(SILENT_Q_FLAG) --pdf -I $(srcdir) \ + $(SILENCE) rm -fr $(ANNOTATE_TEX_TMPS) annotate.t2d/pdf/ + $(ECHO_TEXI2DVI) $(TEXI2DVI_CMD) $(SILENT_Q_FLAG) --pdf -I $(srcdir) \ $(srcdir)/annotate.texinfo annotate.info: $(ANNOTATE_DOC_FILES) @@ -683,6 +698,7 @@ Makefile: Makefile.in $(host_makefile_frag) ../config.status mostlyclean: rm -f gdb.mm gdb.ms gdb.me links2roff + rm -fr annotate.t2d/ stabs.t2d/ gdb.t2d/ rm -f $(GDB_TEX_TMPS) rm -f $(STABS_TEX_TMPS) rm -f $(ANNOTATE_TEX_TMPS) -- 2.25.4 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCHv3 6/6] gdb/doc: fix parallel build of pdf and dvi files 2024-06-06 17:49 ` [PATCHv3 6/6] gdb/doc: fix parallel build of pdf and dvi files Andrew Burgess @ 2024-06-14 19:00 ` Pedro Alves 2024-06-15 9:44 ` Andrew Burgess 0 siblings, 1 reply; 42+ messages in thread From: Pedro Alves @ 2024-06-14 19:00 UTC (permalink / raw) To: Andrew Burgess, gdb-patches; +Cc: Tom Tromey On 2024-06-06 18:49, Andrew Burgess wrote: > When building with 'make -j20 -C gdb/doc all-doc' I often see problems > caused from trying to build some dvi files in parallel with some pdf > files. The problem files are: gdb.dvi and gdb.pdf; stabs.dvi and > stabs.pdf; and annotate.dvi and annotate.pdf. > > The problem is that building these files create temporary files in the > local directory. There's already a race here that two make threads > might try to create these files at the same time. > > But it gets worse, to avoid issues where a failed build could leave > these temporary files in a corrupted state, and so prevent the next > build from succeeding, the recipe for each of these files delete all > the temporary files first, this obviously causes problems if some > other thread has already started the build and is relying on these > temporary files. > > To work around this problem I propose we start using the --build flag > for texi2dvi (which is the same tool used to create the pdf files). > The --build flag allows for the temporary files to be placed into a > sub-directory, e.g. creating gdb.pdf will create the temporary files > in gdb.t2d/pdf/ and gdb.dvi uses gdb.t2d/dvi/, in this way the > temporary files will never clash, and we can easily delete the > specific sub-directory at the start of the recipe to ensure a > successful build. > > Very old versions of texi2dvi don't support --build, so I've added a > configure check for this option. If the option is not supported then > we don't use it. This means we fall back to placing temporary files > in the local directory, which means parallel builds will remain > broken. The --build option is definitely present in texi2dvi version > 6.1, from 2016, so any version after that should be fine. > If we care about old versions enough to support them like this, then couldn't we instead make the subdirectories ourselves and build there, instead of using --build? That way, we would only have one code path, and it would work the same in new or old texi2dvi? I mean, make the rule do something like: mkdir -p pdf && cd pdf && texi2dvi ... ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCHv3 6/6] gdb/doc: fix parallel build of pdf and dvi files 2024-06-14 19:00 ` Pedro Alves @ 2024-06-15 9:44 ` Andrew Burgess 2024-06-15 12:40 ` Eli Zaretskii 0 siblings, 1 reply; 42+ messages in thread From: Andrew Burgess @ 2024-06-15 9:44 UTC (permalink / raw) To: Pedro Alves, gdb-patches; +Cc: Tom Tromey Pedro Alves <pedro@palves.net> writes: > On 2024-06-06 18:49, Andrew Burgess wrote: >> When building with 'make -j20 -C gdb/doc all-doc' I often see problems >> caused from trying to build some dvi files in parallel with some pdf >> files. The problem files are: gdb.dvi and gdb.pdf; stabs.dvi and >> stabs.pdf; and annotate.dvi and annotate.pdf. >> >> The problem is that building these files create temporary files in the >> local directory. There's already a race here that two make threads >> might try to create these files at the same time. >> >> But it gets worse, to avoid issues where a failed build could leave >> these temporary files in a corrupted state, and so prevent the next >> build from succeeding, the recipe for each of these files delete all >> the temporary files first, this obviously causes problems if some >> other thread has already started the build and is relying on these >> temporary files. >> >> To work around this problem I propose we start using the --build flag >> for texi2dvi (which is the same tool used to create the pdf files). >> The --build flag allows for the temporary files to be placed into a >> sub-directory, e.g. creating gdb.pdf will create the temporary files >> in gdb.t2d/pdf/ and gdb.dvi uses gdb.t2d/dvi/, in this way the >> temporary files will never clash, and we can easily delete the >> specific sub-directory at the start of the recipe to ensure a >> successful build. >> >> Very old versions of texi2dvi don't support --build, so I've added a >> configure check for this option. If the option is not supported then >> we don't use it. This means we fall back to placing temporary files >> in the local directory, which means parallel builds will remain >> broken. The --build option is definitely present in texi2dvi version >> 6.1, from 2016, so any version after that should be fine. >> > > If we care about old versions enough to support them like this, then > couldn't we instead make the subdirectories ourselves and build there, > instead of using --build? That way, we would only have one code path, > and it would work the same in new or old texi2dvi? > > I mean, make the rule do something like: > > mkdir -p pdf && cd pdf && texi2dvi ... I took a look at this approach and the problem is fixing all the include paths passed to the texi2dvi command, it all gets a bit messy as we need to add '../' to the start of every include path. I'm happy to drop the configure part of this patch, looking at the texinfo NEWS file the --build=tidy option was added in release 4.9 which came out in June 2007. So if we're willing to make texinfo 4.9 a (doc) build requirement then I'll update the patch. Thanks, Andrew ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCHv3 6/6] gdb/doc: fix parallel build of pdf and dvi files 2024-06-15 9:44 ` Andrew Burgess @ 2024-06-15 12:40 ` Eli Zaretskii 2024-06-15 14:59 ` Andrew Burgess 2024-06-15 15:04 ` Andrew Burgess 0 siblings, 2 replies; 42+ messages in thread From: Eli Zaretskii @ 2024-06-15 12:40 UTC (permalink / raw) To: Andrew Burgess; +Cc: pedro, gdb-patches, tom > From: Andrew Burgess <aburgess@redhat.com> > Cc: Tom Tromey <tom@tromey.com> > Date: Sat, 15 Jun 2024 10:44:13 +0100 > > > If we care about old versions enough to support them like this, then > > couldn't we instead make the subdirectories ourselves and build there, > > instead of using --build? That way, we would only have one code path, > > and it would work the same in new or old texi2dvi? > > > > I mean, make the rule do something like: > > > > mkdir -p pdf && cd pdf && texi2dvi ... > > I took a look at this approach and the problem is fixing all the include > paths passed to the texi2dvi command, it all gets a bit messy as we need > to add '../' to the start of every include path. > > I'm happy to drop the configure part of this patch, looking at the > texinfo NEWS file the --build=tidy option was added in release 4.9 which > came out in June 2007. > > So if we're willing to make texinfo 4.9 a (doc) build requirement then > I'll update the patch. Does the manual even build with such an old version of Texinfo? I very much doubt that, as there were many additions to the language since then. But if 4.9 can still be used, I don't oppose to making the patch support that. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCHv3 6/6] gdb/doc: fix parallel build of pdf and dvi files 2024-06-15 12:40 ` Eli Zaretskii @ 2024-06-15 14:59 ` Andrew Burgess 2024-06-15 15:04 ` Andrew Burgess 1 sibling, 0 replies; 42+ messages in thread From: Andrew Burgess @ 2024-06-15 14:59 UTC (permalink / raw) To: Eli Zaretskii; +Cc: pedro, gdb-patches, tom Eli Zaretskii <eliz@gnu.org> writes: >> From: Andrew Burgess <aburgess@redhat.com> >> Cc: Tom Tromey <tom@tromey.com> >> Date: Sat, 15 Jun 2024 10:44:13 +0100 >> >> > If we care about old versions enough to support them like this, then >> > couldn't we instead make the subdirectories ourselves and build there, >> > instead of using --build? That way, we would only have one code path, >> > and it would work the same in new or old texi2dvi? >> > >> > I mean, make the rule do something like: >> > >> > mkdir -p pdf && cd pdf && texi2dvi ... >> >> I took a look at this approach and the problem is fixing all the include >> paths passed to the texi2dvi command, it all gets a bit messy as we need >> to add '../' to the start of every include path. >> >> I'm happy to drop the configure part of this patch, looking at the >> texinfo NEWS file the --build=tidy option was added in release 4.9 which >> came out in June 2007. >> >> So if we're willing to make texinfo 4.9 a (doc) build requirement then >> I'll update the patch. > > Does the manual even build with such an old version of Texinfo? I > very much doubt that, as there were many additions to the language > since then. You're right. I tried with texinfo 4.13 (I had that kicking around already) and the docs build fails with errors from the .texi files, so I guess we already require a version > 4.13. I'll update the patch and post a new version. Thanks, Andrew ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCHv3 6/6] gdb/doc: fix parallel build of pdf and dvi files 2024-06-15 12:40 ` Eli Zaretskii 2024-06-15 14:59 ` Andrew Burgess @ 2024-06-15 15:04 ` Andrew Burgess 2024-06-21 15:35 ` Pedro Alves 2024-06-25 13:39 ` Andrew Burgess 1 sibling, 2 replies; 42+ messages in thread From: Andrew Burgess @ 2024-06-15 15:04 UTC (permalink / raw) To: Eli Zaretskii; +Cc: pedro, gdb-patches, tom Here's an updated version of just patch #6. In this update: - Removed all the configure nonsense, we already require a version of texinfo greater than 4.9, so I just assume the required options are available. - Now also make use of the --build-dir option (also added in 4.9) to better control the creation of the temporary directories, this makes it easier to cleanup (see mostlyclean recipe). Let me know what you think. Thanks, Andrew --- commit e063bdc6f213f80da0de28a7f84cd31f240a6716 Author: Andrew Burgess <aburgess@redhat.com> Date: Wed May 8 19:12:57 2024 +0100 gdb/doc: fix parallel build of pdf and dvi files When building with 'make -j20 -C gdb/doc all-doc' I often see problems caused from trying to build some dvi files in parallel with some pdf files. The problem files are: gdb.dvi and gdb.pdf; stabs.dvi and stabs.pdf; and annotate.dvi and annotate.pdf. The problem is that building these files create temporary files in the local directory. There's already a race here that two make threads might try to create these files at the same time. But it gets worse, to avoid issues where a failed build could leave these temporary files in a corrupted state, and so prevent the next build from succeeding, the recipe for each of these files deletes all the temporary files first, this obviously causes problems if some other thread has already started the build and is relying on these temporary files. To work around this problem I propose we start using the --build and --build-dir options for texi2dvi (which is the same tool used to create the pdf files). These options were added in texinfo 4.9 which was released in June 2007. We already require using a version of texinfo after 4.9 (I tried to build with 4.13 and the doc build failed as some of the texinfo constructs were not understood), so this patch has not changed the minimum required version at all. The --build flag allows the temporary files to be placed into a sub-directory, and the --build-dir option allows us to control the name of that sub-directory. What we do is create a unique sub-directory for each target that invokes texi2dvi, all of the unique sub-directories are created within a single directory texi2dvi_tmpdir, and so after a complete doc build, we are left with a build tree like this: build/gdb/doc/ '-- texi2dvi_tmpdir/ |-- annotate_dvi/ |-- annotate_pdf/ |-- gdb_dvi/ |-- gdb_pdf/ |-- stabs_dvi/ '-- stabs_pdf/ I've left out all the individual files that live within these directories for simplicity. To avoid corrupted temporary files preventing a future build to complete, each recipe deletes its associated sub-directory from within texi2dvi_tmpdir/ before it attempts a build, this ensures a fresh start each time. And the mostlyclean target deletes texi2dvi_tmpdir/ and all its sub-directories, ensuring that everything is cleaned up. For me, with this fix in place, I can now run 'make -j20 -C gdb/doc all-doc' without seeing any build problems. diff --git a/gdb/doc/Makefile.in b/gdb/doc/Makefile.in index cfd3b3597fb..cf10868ed05 100644 --- a/gdb/doc/Makefile.in +++ b/gdb/doc/Makefile.in @@ -66,8 +66,13 @@ MAKEHTMLFLAGS = # where to find texi2roff, ditto TEXI2ROFF=texi2roff -# where to find texi2dvi, ditto +# Where to find texi2dvi. The use of --build and --build-dir options +# mean that at least texinfo 4.9 is required. TEXI2DVI=texi2dvi +TEXI2DVI_TMPDIR=texi2dvi_tmpdir +TEXI2DVI_CMD = rm -fr $(TEXI2DVI_TMPDIR)/$(subst .,_,$@) \ + && $(TEXI2DVI) --build=tidy \ + --build-dir=$(TEXI2DVI_TMPDIR)/$(subst .,_,$@) # Package to install the docs under PACKAGE = @PACKAGE@ @@ -481,24 +486,17 @@ gdb-cfg.texi: ${srcdir}/${DOC_CONFIG}-cfg.texi ln ${srcdir}/${DOC_CONFIG}-cfg.texi gdb-cfg.texi || \ cp ${srcdir}/${DOC_CONFIG}-cfg.texi gdb-cfg.texi -# Clean these up before each run. Avoids a catch 22 with not being -# able to re-generate these files (to fix a corruption) because these -# files contain a corruption. -GDB_TEX_TMPS = gdb.aux gdb.cp* gdb.fn* gdb.ky* gdb.log gdb.pg* gdb.toc \ - gdb.tp* gdb.vr* - # GDB MANUAL: TeX dvi file gdb.dvi: ${GDB_DOC_FILES} - $(SILENCE) rm -f $(GDB_TEX_TMPS) - $(ECHO_TEXI2DVI) $(TEXI2DVI) $(SILENT_Q_FLAG) $(READLINE_TEXI_INCFLAG) \ - -I ${GDBMI_DIR} -I $(srcdir) $(srcdir)/gdb.texinfo + $(ECHO_TEXI2DVI) $(TEXI2DVI_CMD) $(SILENT_Q_FLAG) \ + $(READLINE_TEXI_INCFLAG) -I ${GDBMI_DIR} -I $(srcdir) \ + $(srcdir)/gdb.texinfo gdb.ps: gdb.dvi $(ECHO_DVIPS) $(DVIPS) $(SILENT_Q_FLAG) -o $@ $? gdb.pdf: ${GDB_DOC_FILES} - $(SILENCE) rm -f $(GDB_TEX_TMPS) - $(ECHO_TEXI2DVI) $(TEXI2DVI) $(SILENT_Q_FLAG) --pdf \ + $(ECHO_TEXI2DVI) $(TEXI2DVI_CMD) $(SILENT_Q_FLAG) --pdf \ $(READLINE_TEXI_INCFLAG) -I ${GDBMI_DIR} -I $(srcdir) \ $(srcdir)/gdb.texinfo @@ -596,44 +594,28 @@ stabs/index.html: $(STABS_DOC_FILES) -I $(srcdir) \ $(srcdir)/stabs.texinfo -# Clean these up before each run. Avoids a catch 22 with not being -# able to re-generate these files (to fix a corruption) because these -# files contain a corruption. -STABS_TEX_TMPS = stabs.aux stabs.cp* stabs.fn* stabs.ky* \ - stabs.log stabs.pg* stabs.toc stabs.tp* stabs.vr* - # STABS DOCUMENTATION: TeX dvi file stabs.dvi : $(STABS_DOC_FILES) - $(SILENCE) rm -f $(STABS_TEX_TMPS) - $(ECHO_TEXI2DVI) $(TEXI2DVI) $(SILENT_Q_FLAG) -I $(srcdir) \ + $(ECHO_TEXI2DVI) $(TEXI2DVI_CMD) $(SILENT_Q_FLAG) -I $(srcdir) \ $(srcdir)/stabs.texinfo stabs.ps: stabs.dvi $(ECHO_DVIPS) $(DVIPS) $(SILENT_Q_FLAG) -o $@ $? stabs.pdf: $(STABS_DOC_FILES) - $(SILENCE) rm -f $(STABS_TEX_TMPS) - $(ECHO_TEXI2DVI) $(TEXI2DVI) $(SILENT_Q_FLAG) --pdf -I $(srcdir) \ + $(ECHO_TEXI2DVI) $(TEXI2DVI_CMD) $(SILENT_Q_FLAG) --pdf -I $(srcdir) \ $(srcdir)/stabs.texinfo -# Clean these up before each run. Avoids a catch 22 with not being -# able to re-generate these files (to fix a corruption) because these -# files contain a corruption. -ANNOTATE_TEX_TMPS = annotate.aux annotate.cp* annotate.fn* annotate.ky* \ - annotate.log annotate.pg* annotate.toc annotate.tp* annotate.vr* - # ANNOTATE DOCUMENTATION: TeX dvi file annotate.dvi : $(ANNOTATE_DOC_FILES) - $(SILENCE) rm -f $(ANNOTATE_TEX_TMPS) - $(ECHO_TEXI2DVI) $(TEXI2DVI) $(SILENT_Q_FLAG) -I $(srcdir) \ + $(ECHO_TEXI2DVI) $(TEXI2DVI_CMD) $(SILENT_Q_FLAG) -I $(srcdir) \ $(srcdir)/annotate.texinfo annotate.ps: annotate.dvi $(ECHO_DVIPS) $(DVIPS) $(SILENT_Q_FLAG) -o $@ $? annotate.pdf: $(ANNOTATE_DOC_FILES) - $(SILENCE) rm -f $(ANNOTATE_TEX_TMPS) - $(ECHO_TEXI2DVI) $(TEXI2DVI) $(SILENT_Q_FLAG) --pdf -I $(srcdir) \ + $(ECHO_TEXI2DVI) $(TEXI2DVI_CMD) $(SILENT_Q_FLAG) --pdf -I $(srcdir) \ $(srcdir)/annotate.texinfo annotate.info: $(ANNOTATE_DOC_FILES) @@ -683,9 +665,7 @@ Makefile: Makefile.in $(host_makefile_frag) ../config.status mostlyclean: rm -f gdb.mm gdb.ms gdb.me links2roff - rm -f $(GDB_TEX_TMPS) - rm -f $(STABS_TEX_TMPS) - rm -f $(ANNOTATE_TEX_TMPS) + rm -fr $(TEXI2DVI_TMPDIR) rm -f refcard.sed sedref.tex sedref_dvi.* sedref_pdf.* rm -f $(POD_FILE_TMPS) ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCHv3 6/6] gdb/doc: fix parallel build of pdf and dvi files 2024-06-15 15:04 ` Andrew Burgess @ 2024-06-21 15:35 ` Pedro Alves 2024-06-24 11:16 ` Andrew Burgess 2024-06-25 13:39 ` Andrew Burgess 1 sibling, 1 reply; 42+ messages in thread From: Pedro Alves @ 2024-06-21 15:35 UTC (permalink / raw) To: Andrew Burgess, Eli Zaretskii; +Cc: gdb-patches, tom On 2024-06-15 16:04, Andrew Burgess wrote: > > Here's an updated version of just patch #6. In this update: > > - Removed all the configure nonsense, we already require a version of > texinfo greater than 4.9, so I just assume the required options are > available. > > - Now also make use of the --build-dir option (also added in 4.9) to > better control the creation of the temporary directories, this makes > it easier to cleanup (see mostlyclean recipe). > > Let me know what you think. Just ran into this myself, which reminded me to reply... :-D LGTM. Approved-By: Pedro Alves <pedro@palves.net> ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCHv3 6/6] gdb/doc: fix parallel build of pdf and dvi files 2024-06-21 15:35 ` Pedro Alves @ 2024-06-24 11:16 ` Andrew Burgess 0 siblings, 0 replies; 42+ messages in thread From: Andrew Burgess @ 2024-06-24 11:16 UTC (permalink / raw) To: Pedro Alves, Eli Zaretskii; +Cc: gdb-patches, tom Pedro Alves <pedro@palves.net> writes: > On 2024-06-15 16:04, Andrew Burgess wrote: >> >> Here's an updated version of just patch #6. In this update: >> >> - Removed all the configure nonsense, we already require a version of >> texinfo greater than 4.9, so I just assume the required options are >> available. >> >> - Now also make use of the --build-dir option (also added in 4.9) to >> better control the creation of the temporary directories, this makes >> it easier to cleanup (see mostlyclean recipe). >> >> Let me know what you think. > > Just ran into this myself, which reminded me to reply... :-D > > LGTM. > > Approved-By: Pedro Alves <pedro@palves.net> I've now pushed this series. Thanks, Andrew ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCHv3 6/6] gdb/doc: fix parallel build of pdf and dvi files 2024-06-15 15:04 ` Andrew Burgess 2024-06-21 15:35 ` Pedro Alves @ 2024-06-25 13:39 ` Andrew Burgess 1 sibling, 0 replies; 42+ messages in thread From: Andrew Burgess @ 2024-06-25 13:39 UTC (permalink / raw) To: gdb-patches; +Cc: pedro, tom, Eli Zaretskii Turns out this commit had a bug in it :( I was sure I'd tested the doc build from an empty build directory, but I guess I managed to mess up and skip this test at some point. As a result the dvi and pdf docs would fail to build due to a missing temporary directory. I've gone ahead and pushed the patch below which addresses this issue. Let me know if there are any further problems. Thanks, Andrew -- commit 9ac999f5007b35d72db67c64a1733edba1171f77 Author: Andrew Burgess <aburgess@redhat.com> Date: Tue Jun 25 14:29:10 2024 +0100 gdb/doc: fix cannot create directory error when building dvi/pdf After this commit: commit 0700386f142f0b0d3d0021995970a1b41c36cc92 (gdb-tmp-c) Date: Wed May 8 19:12:57 2024 +0100 gdb/doc: fix parallel build of pdf and dvi files When building the dvi or pdf targets you'd get errors like this: mkdir: cannot create directory ‘texi2dvi_tmpdir/gdb_dvi’: No such file or directory mkdir: cannot create directory ‘texi2dvi_tmpdir/gdb_pdf’: No such file or directory fixed by ensuring the directory is created before calling texi2dvi. diff --git a/gdb/doc/Makefile.in b/gdb/doc/Makefile.in index cf10868ed05..381ceae35f4 100644 --- a/gdb/doc/Makefile.in +++ b/gdb/doc/Makefile.in @@ -71,6 +71,7 @@ TEXI2ROFF=texi2roff TEXI2DVI=texi2dvi TEXI2DVI_TMPDIR=texi2dvi_tmpdir TEXI2DVI_CMD = rm -fr $(TEXI2DVI_TMPDIR)/$(subst .,_,$@) \ + && mkdir -p $(TEXI2DVI_TMPDIR)/$(subst .,_,$@) \ && $(TEXI2DVI) --build=tidy \ --build-dir=$(TEXI2DVI_TMPDIR)/$(subst .,_,$@) ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCHv3 0/6] gdb/doc: parallel build fixes and improvements 2024-06-06 17:49 ` [PATCHv3 0/6] gdb/doc: parallel build fixes and improvements Andrew Burgess ` (5 preceding siblings ...) 2024-06-06 17:49 ` [PATCHv3 6/6] gdb/doc: fix parallel build of pdf and dvi files Andrew Burgess @ 2024-06-14 18:14 ` Tom Tromey 6 siblings, 0 replies; 42+ messages in thread From: Tom Tromey @ 2024-06-14 18:14 UTC (permalink / raw) To: Andrew Burgess; +Cc: gdb-patches >>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> writes: Andrew> In v3: Andrew> - Add new patch #2 which merges the two man page rules into one. Andrew> - Updated patch #3 based on Eli's feedback. Now use $< instead of a Andrew> shell snippet to locate version.subst. Looks good to me. Approved-By: Tom Tromey <tom@tromey.com> Tom ^ permalink raw reply [flat|nested] 42+ messages in thread
end of thread, other threads:[~2024-06-25 13:39 UTC | newest] Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-05-11 9:37 [PATCH 0/4] gdb/doc: build fixes and improvements Andrew Burgess 2024-05-11 9:37 ` [PATCH 1/4] gdb/doc: don't delete *.pod files too early Andrew Burgess 2024-05-13 16:13 ` Tom Tromey 2024-05-14 15:53 ` Andrew Burgess 2024-05-11 9:37 ` [PATCH 2/4] gdb/doc: don't try to copy GDBvn.texi from the source tree Andrew Burgess 2024-05-13 16:12 ` Tom Tromey 2024-05-13 17:33 ` Eli Zaretskii 2024-05-14 13:32 ` Andrew Burgess 2024-06-14 19:06 ` Pedro Alves 2024-05-11 9:37 ` [PATCH 3/4] gdb/doc: fix parallel build of refcard related targets Andrew Burgess 2024-05-13 16:13 ` Tom Tromey 2024-05-11 9:37 ` [PATCH 4/4] gdb/doc: fix parallel build of pdf and dvi files Andrew Burgess 2024-05-13 16:18 ` Tom Tromey 2024-05-14 13:40 ` Andrew Burgess 2024-05-31 8:18 ` [PATCHv2 0/5] gdb/doc: parallel build fixes and improvements Andrew Burgess 2024-05-31 8:18 ` [PATCHv2 1/5] gdb/doc: don't try to copy GDBvn.texi from the source tree Andrew Burgess 2024-05-31 8:18 ` [PATCHv2 2/5] gdb/doc: allow for version.subst in " Andrew Burgess 2024-05-31 10:40 ` Eli Zaretskii 2024-06-03 14:22 ` Andrew Burgess 2024-06-06 11:59 ` Eli Zaretskii 2024-06-06 17:52 ` Andrew Burgess 2024-05-31 8:18 ` [PATCHv2 3/5] gdb/doc: also look in srcdir when running TEXI2POD Andrew Burgess 2024-05-31 8:18 ` [PATCHv2 4/5] gdb/doc: fix parallel build of refcard related targets Andrew Burgess 2024-05-31 8:18 ` [PATCHv2 5/5] gdb/doc: fix parallel build of pdf and dvi files Andrew Burgess 2024-06-06 17:49 ` [PATCHv3 0/6] gdb/doc: parallel build fixes and improvements Andrew Burgess 2024-06-06 17:49 ` [PATCHv3 1/6] gdb/doc: don't try to copy GDBvn.texi from the source tree Andrew Burgess 2024-06-14 18:45 ` Pedro Alves 2024-06-06 17:49 ` [PATCHv3 2/6] gdb/doc: merge rules for building .1 and .5 man pages Andrew Burgess 2024-06-06 17:49 ` [PATCHv3 3/6] gdb/doc: allow for version.subst in the source tree Andrew Burgess 2024-06-14 18:44 ` Pedro Alves 2024-06-06 17:49 ` [PATCHv3 4/6] gdb/doc: also look in srcdir when running TEXI2POD Andrew Burgess 2024-06-06 17:49 ` [PATCHv3 5/6] gdb/doc: fix parallel build of refcard related targets Andrew Burgess 2024-06-06 17:49 ` [PATCHv3 6/6] gdb/doc: fix parallel build of pdf and dvi files Andrew Burgess 2024-06-14 19:00 ` Pedro Alves 2024-06-15 9:44 ` Andrew Burgess 2024-06-15 12:40 ` Eli Zaretskii 2024-06-15 14:59 ` Andrew Burgess 2024-06-15 15:04 ` Andrew Burgess 2024-06-21 15:35 ` Pedro Alves 2024-06-24 11:16 ` Andrew Burgess 2024-06-25 13:39 ` Andrew Burgess 2024-06-14 18:14 ` [PATCHv3 0/6] gdb/doc: parallel build fixes and improvements Tom Tromey
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).