Monday, May 13, 2024 3:49 PM wrote: David Malcolm <dmalc...@redhat.com> wrote:
> > > > It might be a "make" dependencies issue: > > "make regenerate-opt-urls" has dependencies on OPT_URLS_HTML_DEPS > > which is currently defined as: > > OPT_URLS_HTML_DEPS = $(build_htmldir)/gcc/Option-Index.html \ > > $(build_htmldir)/gdc/Option-Index.html \ > > $(build_htmldir)/gfortran/Option-Index.html > > which might not be enough for the doc changes when moving things > > around that affect other generated html files. > > > > So when the CI runs "make regenerate-opt-urls" in a pristine build it > > will forcibly rerun texinfo to regenerate the docs first, whereas if > > you manually run the script in a build directory, you might not be > > seeing the latest version of the HTML (especially in thre presence of > > file moves). > > > > So I think the Makefile as currently written handles most cases, but > > can get it slightly wrong for the case you ran into here (sorry); > > fully refreshing the built docs ought to fix such cases. > > Specifically, if you have some generated .html files in the > $(build_htmldir) from a file that has gone away (due to a move), then I > suspect > these .html files stick around until you fully delete the $(build_htmldir), > and in > the meantime they get found by regenerate-opt- urls.py and lead to duplicate > enries, leading to differences against a pristine build dir. > > Dave Thank you, Mark and Dave, for clarifying why the patch series encountered this issue! The relocation of opt.urls files and the use of "make regenerate-opt-urls" instead of running the script might explain why resolving duplicates for mthreads has not been triggered earlier. Regards, Evgeny
