I would rather see a heck of a lot of new functions actually. I am really
fed up with some of the limitations of gnu make as it is that might be
solved very easily with even 1 or two well chosen new ones.
Perhaps a warning when one redefines an internal function might be the way
to avoid throttlin
Have you considered the backwards compatibility issues this patch might
cause?
The functions you've implemented for inclusion are implementable
directly in the make language. Therefore, there are very likely
implementations floating around in existing makefiles, very likely with
the names you've
Hello,
I thank the community for their feedback regarding my submission of
$(trimpath ...) and $(relpath ...). Many other benefits to the submission
have been identified which would improve GNU Make if incorporated. However,
I see two outstanding issues which remain:
1) The submission needs to
Edward Welbourne wrote:
Pretty weak. If a few more include paths were added to the project it would
still break, regardless of your patch.
When you have thousands of object files, shortening the name of each
by several bytes when invoking ar can make room for really quite a lot
more files befor
On Tue, May 31, 2011 at 8:06 AM, Edward Welbourne 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
wh
On Tue, 31 May 2011 20:57:10 +0900, Edward Welbourne
wrote:
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.
While this is true, I am not sure one which side this should be solved.
Simply not tre
> Pretty weak. If a few more include paths were added to the project it would
> still break, regardless of your patch.
When you have thousands of object files, shortening the name of each
by several bytes when invoking ar can make room for really quite a lot
more files before you run up against t
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 readabil
Howard,
Thank you for your feedback. I think an example would best justify the
improvements that trimpath and relpath would bring to GNU Make. In fact, I
will give the actual example that motivated me to develop trimpath the
relpath in the first place. We can generalize from that starting point
Ben Robinson wrote:
Eli,
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 functio
Eli,
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 "redunda
> Date: Sun, 29 May 2011 21:45:38 -0700
> From: Ben Robinson
>
> I am submitting a patch which adds two new functions to GNU Make.
Thanks. Please wait for Paul's word about inclusion of these in
Make. What's below are a few comments based on a first impression
from the code.
> $(trimpath name
I am submitting a patch which adds two new functions to GNU Make. The
following description of these two functions is written as documentation,
and is intended for that purpose:
$(trimpath names...)
For each file name in names, returns a name that does not contain any . or
.. components, nor any
13 matches
Mail list logo
