This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: libg++-2.8.1.3 and gcc-20000220 CVS
On Mon, Feb 21, 2000 at 12:44:22AM +0100, Martin v. Loewis wrote:
> > Could we also look into trimming down the prefix? In the original bug
> > report, we really didn't need to see the entire pathname on each line.
>
> Yes, that would be extremely helpful.
A trivial band-aid, it occurs to me, would be a -fmessages-with-basenames
option, causing us to chop off everything up to the last slash if
present. It should probably be named something else.
> > Maybe we could have cpp output file names relative to the place in the
> > #include search path they were found. So with -I /work/src/gcc/gcc,
> > cc1 would see "integrate.c" instead of "/work/src/gcc/gcc/integrate.c".
> > This would also affect __FILE__. It might cause problems with debug
> > info, anyone know what the issues there are?
>
> The debugger would not find the header file when stepping through it;
> you'd have to use gdb's 'dir' command to tell it where header files
> live.
>
> I'd rather see cc1[plus] have both short and long path name at
> disposition. Perhaps in the preprocessor output, the first # line for
> a header file would be the full header path, whereas subsequent
> occurences would be just the shortened versions?
Maybe, but how's it to tell the difference between that and use of
#line in the original? And what if you get an error before the second
# marker?
An alternate idea - put two strings on the # line, first the long
name, then the short one.
> But then, maybe you really need c-cpplib/cxx-cpplib to get it right...
With integrated cpplib, it's easy; the front end gets access to
complete info on the file - its name, its position in the include
path, whether it's a system header, etc - and has only to decide what
to do with it.
zw