Re: improvements to abort()

[craig at jcb-sc dot com]

>If egcs is compiled in the source directory, __FILE__ will be "expr.c"
>for f/expr.c.  I suppose that's an argument for nonrecursive builds.

There are *many* arguments for nonrecursive builds, but there are
equally compelling, and noncontradictory, arguments for making sure
newly introduced features don't assume they're not going to be done
anymore....  (BTW, g77, or more properly the f771 executable and
supporting ones like fini, used to be built from the gcc/ level, but
of course still via recursive builds.  Before that, it was built from
the gcc/f/ level, as it is now, again.  I still haven't investigated
`cook', which gives me some license to fantasize that it's just tons
better than `make'.  :)

>Do you think a magic macro that just trims ^(../)* will be of
>sufficient general utility to put in?  I could just clean up the
>string inside fancy_abort().

I'd prefer the most robust solution possible.  Perhaps what is really
needed is the pathname relative to one known gcc-specific source file,
e.g. tree.c.  So, tree.c could put its __FILE__ into an extern char *,
perhaps without the "tree.c" at the end, then fancy_abort() could strip
off, from whatever filename it wants to print, whatever appears in that
extern as a prefix for that filename, to the extent it matches.

Generally, unless a (purely hypothetical, AFAIK) system fully tracks sources,
versions, etc. in programs, I prefer that products shared between people
not default to putting source pathnames into diagnostics, so I'd prefer to
see no *absolute* pathnames, even if built that way.  At the very
least, avoiding absolute pathnames, e.g. having all gcc-source paths
printed as if they live at "/", as cwd, instead of ".../egcs/gcc/",
avoids printing misleading paths, for cases when the sources have moved,
or just changed, since being used to generate the executable.  Robustly
printing correct pathnames that are *relative* to the location of the
source of the program (executable) being run is something I much prefer,
because that leaves the task of locating the correct *program* source to the
developer, at which point locating the source of the diagnostic *within*
that program (its source files) should be 100% reliable.

So, yes, always printing "../../../" when the build is done the recommended
way just plain looks ugly to me.  :)

But, I support getting rid of that only if doing so doesn't in any way
reduce the reliability of finding the correct source file, within the
source code for the program, from where the diagnostic was issued.

        tq vm, (burley)