Re: New Feature Submission for GNU Make

[Edward Welbourne]

I like what I see ;-)

I haven't looked at the code, but one warning: it's important to not
assume that blah/../foo/ is equivalent to foo/ - blah might be a
symlink.

> *Justification (trimpath)*: trimpath can be used to shorten the 
> input strings to compilers/linkers, as well as improve readability 
> to the user.  Certain compilers have a maximum number of characters 
> which can be passed into a single invocation of their compiler.

Even the shell has an upper bound on how long a command-line it's
willing to be given; it's pretty big, but I've hit that when invoking
ar.  Being able to shorten the path in this way would indeed delay the
point at which a project hits such limits.

Using trimpath may also be helpful in some cases as a way to 
canonicalise filenames (without changing whether they're absolute or 
relative), which is important when dealing with dependencies - ISTR 
that, if the rule to make a file spells its name one way and the 
declaration that something else depends on that file spells it 
differently, make won't notice that the two references are actually to 
the same file; you'll get a "no rule to make" error instead of making 
the needed file.

One can of course use abspath for canonicalisation; but it is apt to 
make command-lines longer; and it causes the output of make to depend 
wantonly on the checkout directory, where systematic use of relative 
paths leaves it easy to diff the output of different builds to detect 
new warnings from the compiler and other changes that should be 
checked up on.  This is, of course, also an argument for relpath ...

> *Justification (relpath)*: Similiar to trimpath, relpath can be used 
> to shorten the input strings to compilers/linkers, as well as 
> improve readability to the user.

When relative paths are used with care, it's even possible to rename a
source tree and its output directory (including assorted .d files
recording dependencies) and remake without problems, as long as the
relative paths between the two are unchanged, where abspath would
force one to invalidate all the prior build's dependency information
(and thus, in effect, do a full re-build just to recreate it, no
matter how little actually needed re-built).

        Eddy.