Re: fix for make gaining jobserver tokens

2011-11-14 Thread Tim Newsome
On Sun, Nov 13, 2011 at 4:19 PM, Paul Smith wrote: > On Tue, 2011-10-25 at 13:34 -0700, Tim Newsome wrote: > > We do a lot of builds (as in double-digit servers building non-stop). > > Sometimes, when a part of the build fails, make -j8 would die with: > > make: INTERNAL: Exiting with 9 jobserver

[bug #34608] comparison of unsigned expression < 0 is always false

2011-11-14 Thread Daniel Herring
Follow-up Comment #13, bug #34608 (project make): Doing it at configure time is quite easy, and just as portable. Specifying negative array lengths will reliably fail at compile time. This trick is already used by several autoconf tests (including AC_COMPUTE_INT last I looked). Again, what you

[bug #34818] PATH_SEPARATOR_CHAR broken for windows when cross-compiled

2011-11-14 Thread Ozkan Sezer
Follow-up Comment #6, bug #34818 (project make): > Cross-compiling for a Windows target sounds funky > to me but I definitely see the attraction there :-) Yep :) I, for one, compile 95% of times on linux rather than on windows or djgpp. __

Re: Using shell wrapper for descrambling parallel make output

2011-11-14 Thread Atte Peltomäki
On Mon, Nov 14, 2011 at 11:46:32AM -0500, David Boyce wrote: > On Mon, Nov 14, 2011 at 4:29 AM, Atte Peltomäki wrote: > > Nice work. Your implementation seems much more refined than mine. Only > > one thing catches my attention; your version doesn't seem to properly > > preserve the original line

[bug #34818] PATH_SEPARATOR_CHAR broken for windows when cross-compiled

2011-11-14 Thread Paul D. Smith
Follow-up Comment #5, bug #34818 (project make): Gotcha. I didn't realize people were using autotools with Windows targets. Cross-compiling for a Windows target sounds funky to me but I definitely see the attraction there :-). ___ Reply t

[bug #34608] comparison of unsigned expression < 0 is always false

2011-11-14 Thread Paul D. Smith
Follow-up Comment #12, bug #34608 (project make): Doing it at configure time is surprisingly difficult. You have to remember that, for any package which wants to properly cross-compile (which we do), you can't actually RUN any test programs during configure time. In order to test it you'd need t

[bug #34608] comparison of unsigned expression < 0 is always false

2011-11-14 Thread Daniel Herring
Follow-up Comment #11, bug #34608 (project make): Don't reopen this for me, but you might consider doing this check at configure time. >From a quick look, I didn't see something like AC_IS_SIGNED. However it shouldn't be hard to wrap AC_COMPILE_IFELSE around an array-bound test that triggers a f

[bug #34818] PATH_SEPARATOR_CHAR broken for windows when cross-compiled

2011-11-14 Thread Ozkan Sezer
Follow-up Comment #4, bug #34818 (project make): > ... For typical Windows, VMS, OS2, etc. builds GNU make doesn't > run autotools (as I understand it). Well, _need_ not run autotools, if one is lazy or especially when building on the native OS itself, provided that he has his own build scripts o

Re: Using shell wrapper for descrambling parallel make output

2011-11-14 Thread David Boyce
On Mon, Nov 14, 2011 at 4:29 AM, Atte Peltomäki wrote: > Nice work. Your implementation seems much more refined than mine. Only > one thing catches my attention; your version doesn't seem to properly > preserve the original line ordering between stdout and stderr. I suggest > solving this as I did

[bug #34818] PATH_SEPARATOR_CHAR broken for windows when cross-compiled

2011-11-14 Thread Paul D. Smith
Follow-up Comment #3, bug #34818 (project make): Maybe I don't understand the context. For typical Windows, VMS, OS2, etc. builds GNU make doesn't run autotools (as I understand it). It has predefined config.h variations for those targets and you copy the right one over to config.h before you bu

[bug #34818] PATH_SEPARATOR_CHAR broken for windows when cross-compiled

2011-11-14 Thread Ozkan Sezer
Follow-up Comment #2, bug #34818 (project make): > A slightly cleaner implementation might have PATH_SEPARATOR_CHAR > defined in the various target-specific config.h files on systems > that don't support autoconf, ... Autoconf _is_ the problem here, because its PATH_SEP detection is not cross-com

[bug #34818] PATH_SEPARATOR_CHAR broken for windows when cross-compiled

2011-11-14 Thread Paul D. Smith
Follow-up Comment #1, bug #34818 (project make): Hi Eli; let me know if you want me to commit this or if you've got it. A slightly cleaner implementation might have PATH_SEPARATOR_CHAR defined in the various target-specific config.h files on systems that don't support autoconf, then in make.h we

Re: Using shell wrapper for descrambling parallel make output

2011-11-14 Thread Atte Peltomäki
On Fri, Nov 11, 2011 at 10:24:25AM -0500, David Boyce wrote: > On Fri, Nov 11, 2011 at 9:26 AM, Atte Peltomäki wrote: > > Hi, > > > > As you know, running parallel builds with '-jX' makes the shell output > > difficult to read, since output from parallel jobs are mixed. To remedy > > this, the use

[bug #34608] comparison of unsigned expression < 0 is always false

2011-11-14 Thread Sebastian Pipping
Follow-up Comment #10, bug #34608 (project make): Very nice, thanks! ___ Reply to this item at: ___ Message sent via/by Savannah http://savannah.gnu.o

[bug #34818] PATH_SEPARATOR_CHAR broken for windows when cross-compiled

2011-11-14 Thread Ozkan Sezer
URL: Summary: PATH_SEPARATOR_CHAR broken for windows when cross-compiled Project: make Submitted by: sezero Submitted on: Mon 14 Nov 2011 11:04:23 AM GMT Severity: 3 - Normal