On Tue, 2023-11-07 at 16:57 +0100, Clément Chigot wrote: > > > However, I'm not sure how you're planning to make the transition. > > > But > > > currently, it looks like libdiagnostics is either enabled and > > > thus > > > the > > > new format being produced, either it's not and we do have the > > > legacy > > > format. I think the transition should be smoother than that, > > > there > > > are > > > probably thousands of tests, scripts, whatever out in the wild > > > expecting this legacy format. Allowing both formats within the > > > same > > > executable, basically chosen by a flag, would probably ease the > > > transition. > > > > Yes. I'm assuming that consumers of libdiagnostics would have a > > configure-time test for the availability of libdiagnostics. In the > > example I gave, it was just a compile-time "choice" (I'm not an > > expert > > at autotools, so I hacked all of that up for now)... but if the > > feature > > is available, it could be a run-time choice. > > > > We've been adding new features to GCC's diagnostic output over the > > years (adding column numbers, showing macro expansions, quoting > > source > > code with underlines, fix-it hints, etc), but each time we've added > > a > > flag to turn them off (e.g. -fno-diagnostics-show-line-numbers, - > > fno- > > diagnostics-show-labels, etc). > > > > As of GCC 11 we have a -fdiagnostics-plain-output which "requests > > that > > diagnostic output look as plain as possible, which may be useful > > when > > running dejagnu or other utilities that need to parse diagnostics > > output and prefer that it remain more stable over time." > > I guess starting by a configure-time choice before such flags like > -fdiagnostics-plain-output are implemented is enough. I merely wish > that there is a way to preserve the old output, giving people the > time > to experiment and then transitioning all their tools. > > We can also introduce a flag like "-fdiagnostics-legacy-output`. > Though, I'm fearing it will never be removed, meaning maintaining the > previous code forever...
One other consideration here may be bootstrapping a toolchain (e.g. bringing up a new CPU architecture) and thus minimizing dependencies. binutils is such an important component that perhaps you'd want to retain a minimal implementation of diagnostics that doesn't bring in an external requirement? especially one based on GCC 14 (which itself requires GCC 4.8 or later to build), e.g. configuring "--without- libdiagnostics" or somesuch? > A configure-time choice can be more easily > enabled by default in a few versions and then removed completely > after > another bunch of versions. > > [...snip...] Dave
