2008/8/25 Arnaud Charlet <[EMAIL PROTECTED]>: >> 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.
My point is that if the rest of the compiler extends diagnostics.c to handle caret and ranges and all other features, Ada would need carry all that around even if gnat has its own diagnostics machinery. But perhaps that is OK. I am not trying to force anything just make you aware of the situation. >> > 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). No, I cannot decide such thing. I would be happy to write such patch, though. >> 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. I see that as very unrealistic, GCC development is already complex enough, so we will have to live with the duplication. I just wanted to make you notice that even if location_t is moved out of libcpp, GNAT will still link with diagnostic.c and whatever other diagnostics features that will be implemented. The burden of the duplication would be on GNAT executable, the other front-ends do not carry GNAT's code. Probably the effect of it is negligible, anyway. >> 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. Again, my point is that even if GNAT has all these features already, GNAT should be interested in this since it means moving stuff out of libcpp which will allow to break that dependency. C/C++ could very well implement caret diagnostics and everything else within libcpp, so the dependency of GNAT with libcpp would be actually harder to break. My fear is that if the other FEs do not care about this issue "because we have it already", then this is exactly what will happen. Cheers, Manuel.
