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.
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
