Am 07.11.2023 um 15:59 schrieb David Malcolm:
On Tue, 2023-11-07 at 08:54 +0100, Simon Sobisch wrote:
Thank you for our work and providing this patch.
GCC related questions:
Is it planned to change GCC diagnostics to use libdiagnostic itself?
No. GCC uses C++ internally, and the internal diagnostic API is
written in C++. libdiagnostic wraps up this C++ API in a C interface.
GCC would continue using the C++ interface internally.
Why not providing both a C and C++ API in libdiagnostics?
GNU programs (and also others) are written in both.
The benefit of using it withing GCC itself "eat your own dogfood" would
be that more or less any need that GCC has is also found in the
library... thinking again, this may also make it "too heavy" - not sure.
Is it planned to "directly" add features or would the result for GCC
be
identical (apart from build changes)?
So far it looks like it wouldn't be possible to "just build
libdiagnostics", and much less to "just distrubute its source" for
that
purpose, is it?
Correct: libdiagnostics is just an extra .cc file within the rest of
GCC, and almost all the work is being done in other .cc files.
Maybe call that "status quo - initial patch"? ;-)
As building GCC does take a significant amount of resources and
system-wide switching to a new GCC version is considered a serious
task
(distributions commonly stay with their major GCC version for quite
some
time), I'd search for an option to building a "self-contained"
version
that does not need the complete necessary toolset and may also be
distributed separately.
It's possible to reduce the resources by disabling bootstrapping, and
only enabling a minimal set of languages.
I'd see libdiagnostics as coming from the distribution build of GCC. I
suppose distributions might want to have a simple build of GCC and ship
just the .so/.h file from libdiagnostics from the build.
Agreed. But I'm as a "user" would like to have that "easy" option, too.
As a maintainer that plans to move to libdiagnostics it would be _very_
helpful to be able to use it as a sub-project, in case it isn't available.
This definitely can come later, too; I _guess_ this would mean moving
part of GCCs code in a sub-folder libdiagnostics and use it as
subproject for configure/make, with then option to run "make dist" in
that subfolder alone, too.
It would involve a lot of refactoring :)
Something to "consider along, do later", I guess.
The main reason for that would be to allow applications move from
their previous own diagnostic to libdiagnostics, if it isn't available on
the system they can build and install it as subproject, too; and to be
able to build libdiagnostics with a much reduced dependency list.
I can try to come up with a minimal recipe for building gcc if all you
want is libdiagnostics
Thanks, that already helps a lot.
Simon
