Re: New Feature Submission for GNU Make

[David Boyce]

On Tue, May 31, 2011 at 8:06 AM, Edward Welbourne <address@hidden> wrote:
> Never understimate the value of a modest shortening of file names -
> when our ar command-line got to about 230 kibibytes, we had to re-work
> the way we invoked ar !

My vote would be favorable as well. There are a number of subtleties
which should not be underestimated:

- Really long lines in a logfile makes it hard to visually process
them and detect errors or warnings.

- Long lines cause logfiles themselves to take up more space which can
cause them to fill partitions, force an organization to carry fewer
old logs, etc. Where I work we have a nightly build report with
clickable links to logfiles. It can take quite a while for a browser
to load up a big logfile, especially for colleagues working over slow
lines.

- As noted before, the ability to compare logfiles with relativized
paths is helpful, as is the ability to take the failing command line
from someone else's build output and copy and paste it into your
workspace for debugging.

- Objects built for debug tend to have full paths to source files
built in. Shortening the paths can thus shrink the objects themselves
and make debugging more easily portable. Also some organizations may
want to ship debug objects without exposing their internal development
infrastructure.

Of course it's possible to do some relativizing now with a combination
of abspath and subst, but it's not fully robust.

I think that "canonpath" would be a better name than "trimpath"; more
mnemonic, more standard.

David Boyce