On Mon, 2024-05-13 at 11:14 +0200, Mark Wielaard wrote:
> Hi Evgeny,
>
> Adding David to the CC, who might know the details.
>
> On Mon, May 13, 2024 at 08:44:12AM +0000, Evgeny Karpov wrote:
> > Sunday, May 12, 2024
> >
> > Thank you for reviewing our changes related to the refactoring of
> > extracting the MinGW implementation from ix64.
> >
> > It was expected to move the MinGW-related files without changes in
> > this commit ("Reuse MinGW from i386 for AArch64") and apply the
> > renaming in a follow-up commit, which has been done in 'Rename "x86
> > Windows Options" to "Cygwin and MinGW Options"'.
> >
> > The script to update opt.urls files has been used.
> >
> > > diff --git a/gcc/config/mingw/cygming.opt.urls
> > > b/gcc/config/mingw/cygming.opt.urls
> > > index c624e22e4427..af11c4997609 100644
> > > --- a/gcc/config/mingw/cygming.opt.urls
> > > +++ b/gcc/config/mingw/cygming.opt.urls
> > > @@ -1,4 +1,4 @@
> >
> > > -; Autogenerated by regenerate-opt-urls.py from
> > > gcc/config/i386/cygming.opt
> > > and generated HTML
> > > +; Autogenerated by regenerate-opt-urls.py from
> > > +gcc/config/mingw/cygming.opt and generated HTML
> >
> > I am not sure why this comment has not been updated. Is it critical
> > or it could be updated next time when it is needed?
>
> Odd that the script didn't update this comment, it really should
> have.
> It might be that running the script through make regenerate-opt-urls
> inside the gcc build subdir invokes regenerate-opt-urls.py slightly
> differently so that this line is updated.
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.
That's my theory of what happened here, anyway.
Dave
>
> > > mconsole
> > > UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mconsole)
> > > @@ -9,9 +9,8 @@ UrlSuffix(gcc/Cygwin-and-MinGW-
> > > Options.html#index-
> > > mdll)
> > > mnop-fun-dllimport
> > > UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mnop-fun-
> > > dllimport)
> > >
> > > -; skipping UrlSuffix for 'mthreads' due to multiple URLs:
> > > -; duplicate: 'gcc/Cygwin-and-MinGW-Options.html#index-
> > > mthreads-1'
> > > -; duplicate: 'gcc/x86-Options.html#index-mthreads'
> > > +mthreads
> > > +UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mthreads-1)
> >
> > mthreads has the same issue before applying changes. Has something
> > been changed recently?
> > This is the change in patch series in 'Rename "x86 Windows Options"
> > to "Cygwin and MinGW Options"' commit.
> >
> > ; skipping UrlSuffix for 'mthreads' due to multiple URLs:
> > +; duplicate: 'gcc/Cygwin-and-MinGW-Options.html#index-mthreads-
> > 1'
> > ; duplicate: 'gcc/x86-Options.html#index-mthreads'
> > -; duplicate: 'gcc/x86-Windows-Options.html#index-mthreads-1'
>
> Again, it might be caused by invoking the script by hand vs with make
> regenerate-opt-urls.py. I believe with the make option it will
> renumber the suffixes making sure the urls are unique.
>
> BTW. There is a CI buildbot that tries to regenerate all generated
> files, which is how I spotted this:
> https://builder.sourceware.org/buildbot/#/builders/gcc-autoregen
> (It should also sent email to the author of the patch on failure.)
>
> Cheers,
>
> Mark
>
