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
