[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New Feature Submission for GNU Make

From: Howard Chu
Subject: Re: New Feature Submission for GNU Make
Date: Mon, 30 May 2011 12:27:01 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b13pre) Gecko/20110322 Firefox/4.0b13pre SeaMonkey/2.1b2pre

Ben Robinson wrote:

Thank you for your constructive criticism regarding my submission to GNU Make.
  I perceive the critiques to fall into three categories (documentation,
justification and code improvements) which I will respond to in order.

*Documentation*: You are correct, these functions remove only "redundant" or
"unnecessary" . and .. components.  The suggested documentation should instead

$(trimpath names|...|)
For each file name innames,returns a name that does not contain
any|unnecessary.|or|..|components, nor any repeated path separators (|/|).
  Canonical absolute names remain canonical absolute, and relative names
remain relative.

$(relpath names|...|)
For each file name innames,returns the relative path to the file.  This
relative path does not contain anyunnecessary |.|or|..|components, nor any
repeated path separators (|/|).

*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.  In my project, I had a dozen or so
-include<search_path> which contained many unnecessary . and .. components,
which caused the compiler to overflow the input buffer.  While it is
unfortunate compilers exist with unreasonably small input buffers, trimpath
allowed me to only pass in the minimum number of characters required
to successfully compile.

Pretty weak. If a few more include paths were added to the project it would still break, regardless of your patch.

Also, the readability of paths printed to the console is greatly improved by
trimpath.  I was regularly dealing with paths of the following structure:


which would be reduced by trimpath to:


At first glance this sounds like a good thing, but it seems to miss the possibility of weirdly symlinked build trees, where "foo/bar/.." != "foo".

  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]