From: [email protected] (Christos Zoulas), Date: Wed, 10 Jul 2013 15:08:39 +0000 (UTC)
> In article <[email protected]>, > Ryo ONODERA <[email protected]> wrote: >>From: [email protected] (Christos Zoulas), Date: Wed, 10 Jul 2013 >>13:08:49 +0000 (UTC) >> >>> In article <[email protected]>, >>> Christos Zoulas <[email protected]> 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 "$@" Thanks for your explanation. In pkgsrc case, shell script may work. Outside pkgsrc, some program may be broken by this make(1) change. I vote to "revert the changes so that MAKELEVEL again works the same way as in gmake". Thank you. -- Ryo ONODERA // [email protected] PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
