> > 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
