RE: suggestion: new make function

2011-10-12 Thread Lawrence Ibarria
Murphy; bug-make@gnu.org; make-...@gnu.org > Subject: RE: suggestion: new make function > > On Tue, 2011-10-11 at 11:03 -0700, Lawrence Ibarria wrote: > > > -Original Message- > > > From: bug-make-bounces+libarria=nvidia@gnu.org [mailto:bug- > make- > &g

RE: suggestion: new make function

2011-10-12 Thread Paul Smith
17 PM > > To: Tim Murphy > > Cc: bug-make@gnu.org; make-...@gnu.org > > Subject: Re: suggestion: new make function > > > > I agree with Tim and with Tim's suggested API, in particular > > "withfile". Involving the shell in something as basic and inherent

RE: suggestion: new make function

2011-10-11 Thread Lawrence Ibarria
> Cc: bug-make@gnu.org; make-...@gnu.org > Subject: Re: suggestion: new make function > > I agree with Tim and with Tim's suggested API, in particular > "withfile". Involving the shell in something as basic and inherently > portable as writing to a file opens up a w

Re: suggestion: new make function

2011-09-27 Thread Edward Welbourne
> I have limited sympathy for this type of situation, "multifile > compilation" is against the general idea of make. On the other hand, running ar once per .o file cost time (at least) quadratic in the number of files, when I tried it. So "multifile archiving" is perfectly standard - and it's usu

Re: suggestion: new make function

2011-09-25 Thread David Boyce
I agree with Tim and with Tim's suggested API, in particular "withfile". Involving the shell in something as basic and inherently portable as writing to a file opens up a world of portability issues, in addition to the performance and readability problems mentioned. Given that some platforms (Windo

Re: suggestion: new make function

2011-09-25 Thread Norbert Thiebaud
> > I find your suggestions more elagant than the original, they seem more > general purpose, and less "let's introduce this feature to get around > a specific problem". Of your two suggestions, I'd favor the "withfile" > option, it would be both more powerful, and doesn't introduce the > problem o

Re: suggestion: new make function

2011-09-25 Thread Luke Shumaker
At Sun, 25 Sep 2011 19:36:26 +0100, Tim Murphy wrote: > My apologies to Luke for forgetting "reply to all" and for forgetting > my manners by using the word "sucks" when I should not have. Now it's my turn to apologize, I just forwarded your original message to me to the list. Sorry. > > dumpOneL

Fwd: Re: suggestion: new make function

2011-09-25 Thread Luke Shumaker
You didn't CC the list --- Begin Message --- I use the foreach "trick" and it utterly sucks. It's complicated and tends to execute the shell 10x more than it needs to. For small makefiles it doesn't matter but doing this for compiles (e.g. the ARM RVCT's multifile compilation option) in a large m

Re: suggestion: new make function

2011-09-25 Thread Tim Murphy
My apologies to Luke for forgetting "reply to all" and for forgetting my manners by using the word "sucks" when I should not have. > I vote 'no'. This can easily be implemented in your > Makefile. (assuming no single list item breaks the limit) > > dumpOneLine = $(foreach item,$(2),echo -n '$(item

Re: suggestion: new make function

2011-09-25 Thread Luke Shumaker
At Tue, 20 Sep 2011 12:09:42 -0700, Lawrence Ibarria wrote: > I have often hit problems with the limit of command line lengths > many shells have (CMD.EXE in Windows in my case). > This is a common case with few solutions, I have searched around: > > http://www.makelinux.net/make3/make3-CHP-5-SECT