URL:
http://savannah.gnu.org/bugs/?34818
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
Follow-up Comment #10, bug #34608 (project make):
Very nice, thanks!
___
Reply to this item at:
http://savannah.gnu.org/bugs/?34608
___
Message sent via/by Savannah
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 atte.peltom...@iki.fi 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
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
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
On Mon, Nov 14, 2011 at 4:29 AM, Atte Peltomäki atte.peltom...@iki.fi 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
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 or
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
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
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 atte.peltom...@iki.fi 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
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.
___
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
On Sun, Nov 13, 2011 at 4:19 PM, Paul Smith psm...@gnu.org 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
13 matches
Mail list logo
