GNOME Bugzilla – Bug 697940
Race condition between setup-build.stamp and scan-build.stamp
Last modified: 2017-10-05 15:16:40 UTC
gtkdoc-scan does this: my $sections_file = "${OUTPUT_DIR}/$MODULE-sections.txt"; if ($REBUILD_SECTIONS || ! -e $sections_file) { `cp $old_decl_list $sections_file`; } my $overrides_file = "${OUTPUT_DIR}/$MODULE-overrides.txt"; if (! -e $overrides_file) { `touch $overrides_file`; } OUTPUT_DIR is usually ".", which is a subdirectory in the build directory (i.e. builddir/doc/reference/gtk). The code above will always create a new overrides and new sections files, because it looks for them in the build directory. If software developer provided custom overrides or sections files, these will just stay in the source directory (i.e. srcdir/doc/reference/gtk), and gtkdoc won't look at them. That leads to build-time errors.
The setup-build.stamp: target in gtk-doc.make copies the files from SRCDIR to BUILDDIR if needed.
scan-build.stamp runs the scanner, which will create new overrides and sections files, if they don't exist. setup-build.stamp copies these files from the source dir, if they don't exist. setup-build.stamp is a prerequisite for tmpl-build.stamp, but so are sections and overrides files, and their prerequisite is the scan-build.stamp When -j is used, scan-build.stamp and setup-build.stamp can (and will) run concurrently, and the outcome is not pre-determined (though more often than not scan-build.stamp wins and creates new overrides and sections files).
MAKEFLAGS=-j1 :/ Also forget about tmpl-build.stamp, thats deprecated, per default the notmpl variant is used. I won't have much time to debug this in the near future.
(In reply to comment #3) > MAKEFLAGS=-j1 :/ That conflicts with -j8 that i use to speed up builds on Windows. Because everything that forks is slow there. > Also forget about tmpl-build.stamp, thats deprecated, per default the notmpl > variant is used. You mean gtkdocize will install the notml version? I've looked at its source code, and that failed to figure that out, so i'm asking here. Also, whatever gtkdocize does, it does not affect existing gtk-doc-using packages. Or are you saying that gtkdocize should be used to prepare the source tree (the same way autoreconf is)? Also, it doesn't matter. tmpl-build.stamp is just the first target that has both setup-build.stamp and -sections.txt and -overrides.txt (and, indirectly, scan-build.stamp) as prerequisites. sgml-build.stamp is the second stamp that has these prerequisites. > > I won't have much time to debug this in the near future. Adding setup-build.stamp as a prerequisite to scan-build.stamp fixed this for me, it seems.
(In reply to comment #4) > (In reply to comment #3) > > MAKEFLAGS=-j1 :/ > That conflicts with -j8 that i use to speed up builds on Windows. Because > everything that forks is slow there. You can specify MAKEFLAGS=-j1 in the Makefile.am that do the docs, so it will only affect the docs. > > > Also forget about tmpl-build.stamp, thats deprecated, per default the notmpl > > variant is used. > You mean gtkdocize will install the notml version? I've looked at its source > code, and that failed to figure that out, so i'm asking here. You can ask for the flavour in configure.ac, e.g.: GTK_DOC_CHECK([1.16],[--flavour no-tmpl]) > > Also, whatever gtkdocize does, it does not affect existing gtk-doc-using > packages. Or are you saying that gtkdocize should be used to prepare the source > tree (the same way autoreconf is)? gtkdocize is run during bootstrap already. > > Also, it doesn't matter. tmpl-build.stamp is just the first target that has > both setup-build.stamp and -sections.txt and -overrides.txt (and, indirectly, > scan-build.stamp) as prerequisites. sgml-build.stamp is the second stamp that > has these prerequisites. > > > > > I won't have much time to debug this in the near future. > Adding setup-build.stamp as a prerequisite to scan-build.stamp fixed this for > me, it seems. Sounds sane, if I only could remember for what reason I did not added it there. Will sleep over it.
(In reply to comment #5) > You can specify MAKEFLAGS=-j1 in the Makefile.am that do the docs, so it will > only affect the docs. ".NOTPARALLEL:" is a nicer way to do this, at least for GNU make. > > Adding setup-build.stamp as a prerequisite to scan-build.stamp fixed this for > > me, it seems. > > Sounds sane, if I only could remember for what reason I did not added it there. > Will sleep over it. Any update on this? I think this might be the root cause of Bug #723653.
commit af3bf981888ceeb05d6c13d18dcf91e03165dba9 Author: Stefan Sauer <ensonic@users.sf.net> Date: Thu Feb 6 20:18:32 2014 +0100 make: add dependency on setup-build.stamp for scan: This fixes issues with parallel builds. Fixes #697940
*** Bug 723653 has been marked as a duplicate of this bug. ***