This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Better GCC diagnostics
> > Well, clearly, the preprocessor and handling of #include is very
> > C/C++ specific, and not used by Ada or Fortran.
>
> Both Ada and Fortran are linked with libcpp.a.
Sure, because as we've said, libcpp is not modular enough. Clearly Ada does not
need to link with A C preprocessor at all.
> Even if you do not use line-map.o, the middle-end does, so you still
> have the duplication.
Right, this is the only part that is indeed shared and for which Ada requires
libcpp.
> > It has also handled column info from day one (and we would not want any
> > of the e.g. -fshow-column stuff: why would you *not* want to display
> > column information ? :-)
>
> Yes, why?
So, I assume there are plans to get rid of -fshow-column switch (and make it the
only default).
> The point is that other front-ends would be able to use it. And
> non-Ada developers would be able to fix it and extend it. Moreover,
I certainly have no problem giving access to other front-ends to GNAT's
capability here, as long as everyone is cool with using Ada in other front-ends,
I'm certainly all for it.
> even if GNAT won't use it, moving all this out of libcpp and making it
> modular would allow to link only to the things that you really need.
Definitely.
> Finally, the middle-end is using it anyway, so gnat is using it.
Sure. Using line-map is one thing, using a C preprocessor is another.
Arno