Re: CVS commit: src/usr.bin/make

[christos%astron.com@localhost (Christos Zoulas)]

In article <20130710.232445.202823964487691297.ryo_on%yk.rim.or.jp@localhost>,
Ryo ONODERA  <ryo_on%yk.rim.or.jp@localhost> wrote:
>From: christos%astron.com@localhost (Christos Zoulas), Date: Wed, 10 Jul 2013
>13:08:49 +0000 (UTC)
>
>> In article <krbu04$2j1$1%ger.gmane.org@localhost>,
>> Christos Zoulas <christos%astron.com@localhost> wrote:
>>>>Module Name:        src
>>>>Committed By:       sjg
>>>>Date:               Sat Jul  6 18:19:17 UTC 2013
>>>>
>>>>Modified Files:
>>>>    src/usr.bin/make: main.c var.c
>>>>
>>>>Log Message:
>>>>If using gmake's MAKELEVEL; use it the same way
>>>
>>>Now you put it back the way it was before which is wrong. Gmake does not
>>>behave this way. Before your change the following Makefile printed:
>> 
>> This is still broken. Renaming the variable is not a fix either.
>> Consider the case where we switched from bmake to gmake as the
>> pkgsrc wrapper. The packages that depend on $MAKELEVEL being 0 or
>> unset would still break. So the proper fix for the 2 packages that
>> broke is to make pkgsrc unset MAKELEVEL before invoking gmake.
>> 
>> So to fix those:
>> - revert the changes so that MAKELEVEL again works the same way as in gmake.
>> - add glue to invoke gmake with MAKELEVEL unset.
>
>Hi,
>
>I feel second idea is not so good.
>Because pkgsrc creates symlink, work/.tools/bin/make, for our make and gmake.
>So with gmake in USE_TOOLS, it is symlink for /usr/pkg/bin/gmake,
>and without gmake in USE_TOOLS, it is for /usr/bin/make.
>I cannot distinguish them with filename.

It is simple:

1. You unset it for all (easiest+safest)
2. You create a shell script instead of a symlink that does:
    unset MAKELEVEL && exec /usr/pkg/bin/gmake "$@"

christos