Follow-up Comment #7, bug #30370 (project make):
Thanks for the comments.
Yes, supporting multiple masks directly in the dependency matching, based on
regular expressions, is fundamentally different from using dynamically set
variables as pseudo-masks which is what the
Follow-up Comment #3, bug #30328 (project make):
Hi Paul,
Is it really true that this is an issue?
At least in our build there are about to do this and having done that
log/trace echo commands in all recipes.
Using Cygwin with its high process creation overhead the proposed change gave
a
Follow-up Comment #3, bug #30323 (project make):
Hi Eli,
GetModuleFileName is available on Windows 9X as well.
I see. Thanks for the hint.
So I think the current code is allright even on older Windows versions.
If you have a practical case weher this API doesn't work on Windows 9X,
Follow-up Comment #7, bug #30381 (project make):
Paul,
I don't think it's complicated to describe. %: %.o and %.o: %.c don't
shorten the search target so they can't be used twice, while %.made: % does.
All the cases in my own makefiles are of the second type anyway. This is only
considered
Follow-up Comment #8, bug #30381 (project make):
Somehow the verbatim tags ate most of my descriptions (a preview facility
would be really nice), retry:
(imagine verbatim on)
(6) d. For each prerequisite that does not exist, follow this algorithm
recursively to see if the prerequisite can be
On Mon, 2010-07-19 at 11:29 +0200, Edward Welbourne wrote:
Probably there should be an effort to switch to heap for anything that
might get large and reserve alloca() usage just for things we know for a
fact will not get too large, but that hasn't been done.
... and anywhere you use a
Follow-up Comment #4, bug #30328 (project make):
Make can handle simple quoting without falling back to the shell, including
the difference between single- and double-quotes etc.
___
Reply to this item at:
Probably there should be an effort to switch to heap for anything that
might get large and reserve alloca() usage just for things we know for a
fact will not get too large, but that hasn't been done.
... and anywhere you use a scanf variant, glibc is also using
alloca(), without knowing any
Follow-up Comment #5, bug #30328 (project make):
I'd like to add one point about this feature being extremely useful from a
performance point of view.
I certainly have come across large makefiles where $(shell) for appending to
a file is like crask - you desperately need to do it but it has a
Follow-up Comment #6, bug #30328 (project make):
what about to have some function $(file file_name,open_type,string)
where open_type can be the same as for fopen
static void replace_all(char* inputStr,const char* pattern,const char*
substr) {
char * found = strstr(inputStr,pattern);
On 7/19/2010 4:01 AM, anonymous wrote:
Using Cygwin with its high process creation overhead the proposed change gave
a speedup in the high single-digit procent range.
Are you running on a 64-bit Windows OS? Cygwin's process creation on
64-bit Windows is currently ~6
times slower than on
11 matches
Mail list logo
