Re: [bug #30328] Fast echo (with code proposal)

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 32-b

[bug #30328] Fast echo (with code proposal)

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); int

[bug #30381] Don't avoid implicit rule recursion quite so soon.

Follow-up Comment #9, bug #30381 (project make): Maybe we can use something like %(1).foo%(2) : %(1)a%(2) So your example will look like %(1).foo : %(1)a%(1) I agree with Reiner. make can be better and has more features, then current implementation. At least all functions from http://gmsl.s

[bug #30328] Fast echo (with code proposal)

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 te

Re: Setting RLIMIT_STACK

> 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

[bug #30328] Fast echo (with code proposal)

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:

Re: Setting RLIMIT_STACK

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 us

[bug #30381] Don't avoid implicit rule recursion quite so soon.

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 ma

[bug #30381] Don't avoid implicit rule recursion quite so soon.

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

[bug #30323] No path in MAKE_COMMAND (with fix)

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, ple

[bug #30328] Fast echo (with code proposal)

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

[bug #30370] add a shorthand syntax for foreach-eval-call

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 foreach-call-eval-soluti