[PATCH 2/2] libdiagnostics: work-in-progress implementation

[Simon Sobisch]

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