libdiagnostics name clash

[David Malcolm]

On Thu, 2024-11-21 at 08:08 +0200, Eli Zaretskii wrote:
> > Date: Wed, 20 Nov 2024 16:11:16 -0500
> > From: David Malcolm via Gcc <gcc@gcc.gnu.org>
> > 
> > I merged libdiagnostics to GCC trunk on Monday:
> >   https://gcc.gnu.org/wiki/libdiagnostics
> > 
> > Unfortunately I've since discovered there's at least one
> > libdiagnostics
> > .so already in Debian:
> > https://tracker.debian.org/pkg/diagnostics
> > https://packages.debian.org/search?searchon=contents&keywords=libdiag&mode=filename&suite=unstable&arch=any
> > 
> > so I've been asked to change the name.
> > 
> > I'd prefer to avoid having "gcc" in the name.
> 
> Why do prefer not to mention "gcc" in the name?

Three reasons:

(a) structural: eventually we might want to split this code out into a
separate source tree from gcc (though I don't see that happening any
time soon, a *lot* of refactoring would be needed).

(b) layering: we already have a useful separation in gcc's source tree
between generic diagnostic functionality vs gcc-specific functionality.
It's helpful for that for the generic functionality to not have "gcc"
in the title.

(c) political: I'm worried that if the project has "gcc" in the name
that it might be an impediment to 3rd party projects using it; in
theory any GPL-compatible project might find it useful

> 
> > Some name ideas:
> > 
> > * libdiag
> > * libgdiagnostics (where we can be ambiguous about what the "g"
> > stands
> > for)
> > * libgdiag (less typing)
> > * libcomplain
> > * libcomplaint
> > * libwhining
> > * libwhine (but sounds like the Windows compat software)
> > 
> > Any ideas?
> 
> FWIW, libgdiag sounds best (but libgccdiag or libdiag-gcc would be
> even better).

Thanks.

I'm testing a patch that renames "libdiagnostics" to "libgdiagnostics",
but doesn't touch the names of the API entrypoints (but am about to
disappear for a 2 day US holiday).

Dave