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
