Follow-up Comment #5, bug #35384 (project make):
Yes, it's a duplicate. We can close this one.
If there's anything I can do for 35147 let me know. My work maintains large
make-based builds and I don't know how many times we've run into the "argument
list too long" issue, usually shortly before a
Follow-up Comment #4, bug #35384 (project make):
I don't see a way to mark it formally but note that this proposal is very much
the same as #35147. There was also a long thread on the bug-make mailing list
quite recently (late 2011?) discussing proposals in detail, and more or less
coming to agree
Follow-up Comment #6, bug #35063 (project make):
I think the root of our disagreement is in the goals. This is not at all about
adding url encode/decode capability to make; it's about a consistent, safe way
of getting special characters past the make parser and I suggested url
encoding (aka percen
Follow-up Comment #5, bug #35063 (project make):
Well, when saying "altering the basic syntax" I mean changing the semantics of
'$(...)' notation, which currently stands for expanding a variable reference
or invoking a built-in function.
Personally for me it is unclear what '$(%20)' or '$(.%20)'
Follow-up Comment #4, bug #35063 (project make):
I don't agree with this, and I don't know what you mean about altering the
basic syntax. The original proposal makes no change to syntax (although I see
that I used the word incorrectly in the subject line), it adds a new range of
built-in variables
Follow-up Comment #3, bug #35063 (project make):
I would vote up for just adding two new functions, i.e. `url-encode` and
`url-decode`, without altering the basic syntax. Both functions are simple
enough to implement.
Thus, the suggested usage is the following:
_space := $(url-decode %20)
The
