On Wed, Nov 22, 2023 at 23:15:56 +0000, Joseph Myers wrote:
> On Mon, 20 Nov 2023, Ben Boeckel wrote:
> 
> > Bugzilla is preferred today.
> > 
> > ChangeLog:
> > 
> >     * config-ml.in: Replace gcc-bugs@ with Bugzilla link.
> >     * symlink-tree: Replace gcc-bugs@ with Bugzilla link.
> 
> I don't think we should use a URL that redirects (i.e. 
> https://gcc.gnu.org/bugzilla should preferably have a trailing '/'), and 
> arguably we should use https://gcc.gnu.org/bugs/ as the URL; that's the 
> preferred one to point people to for bugs in the compilers themselves, 
> since it gives more instructions on bug reporting (though those 
> instructions may be less relevant for bugs in these files).

I'll update the URL.

> codingconventions.html claims that symlink-tree is "copied from mainline 
> automake".  That is, I think, out-of-date information: automake's 
> contrib/multilib/README says "The master (and probably more up-to-date) 
> copies of the 'config-ml.in' and 'symlink-tree' files are maintained in 
> the GCC development tree".  But it does indicate that 
> codingconventions.html itself should be updated to stop suggesting 
> symlink-tree is maintained elsewhere.

I'll also change that.

> > libcpp/ChangeLog:
> > 
> >     * configure: Replace gcc-bugs@ with Bugzilla link.
> >     * configure.ac: Replace gcc-bugs@ with Bugzilla link.
> > 
> > libdecnumber/ChangeLog:
> > 
> >     * configure: Replace gcc-bugs@ with Bugzilla link.
> >     * configure.ac: Replace gcc-bugs@ with Bugzilla link.
> 
> I hope the configure changes are the same as you get with regeneration 
> with the right autoconf version, and so should be described as 
> regeneration in the ChangeLog entries.

Is there a version of autoconf I should use? I have 2.71 laying around
but see that these were generated with 2.69. If you want me to regen
with 2.71, I'll do that as separate prep commits so that this diff is
sensible. Or I can try and dig up a 2.69 in some container to do it.

Thanks,

--Ben

Reply via email to