GNU bug report logs -
#7868
parallel-tests and command-line length limit issue
Previous Next
Full log
View this message in rfc822 format
Hi Bob.
On 12/30/2011 05:10 PM, Bob Friesenhahn wrote:
> On Fri, 30 Dec 2011, Stefano Lattarini wrote:
>>>
>> OK, I hope I've finally managed to partially fix this incredibly annoying bug
>> -- I say "partially" because the fix is sadly *for GNU make*. Even more sadly,
>> the solution is pretty hacky and somewhat brittle. Still, it should cause no
>> regression with the non-GNU makes (as they will continue to use the old
>> implementation), and I have verified that it works with at least all the GNU
>> make versions >= 3.78.
>
> I see that there is a new test which tests for GNU make. How solid is it?
>
Pretty solid IMHO. In fact, it correctly exposes the problem at hand in the
following setups:
* Solaris 10 with /usr/ccs/bin/make
* Solaris 10 with GNU make 3.82
* Debian unstable with GNU make 3.81, freebsd-make (8.x) and
pmake (port of NetBSDmake)
* NetBSD 5.1 with the system make
On Cygwin 1.5, it exposes a probably-related problem (a segfault in make).
> For example, the GNU make I use under MinGW is called 'csmake' (for
> "Case Sensitive make") because the default MinGW GNU case-insensitive
> make is horrendously slow... [SNIP] ... As a result, whenever I would
> normally type 'make' I type 'csmake' instead.
>
Then, to be 100% correct, you'll have to call configure as:
./configure MAKE=csmake
Still, if you only have GNU make installed on you system, the correct
code paths in the generated Makefile will be correctly activated even
if you don't specify the $MAKE override at configure time, so you will
later be able to safely run the generated Makefiles with other versions
of GNU make.
Regards,
Stefano
This bug report was last modified 4 years and 205 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.