Removal of use_gmake breaks lua

[Chris Rees]

On 17 December 2011 18:53, Jan Beich <jbeich at tormail.net> wrote:
> Chris Rees <crees at freebsd.org> writes:
>
>>> Chris Rees <crees at freebsd.org> writes:
>>>
>>>>> as seen here:
>>>>> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=295602+0+/usr/local/www/db/text/2011/cvs-all/20111113.cvs-all
>>>>
>>>> I don't like the proposed solution; it's less hackish to just use
>>>> gmake again; most people have it installed anyway....
>>>
>>> A non-hackish solution would involve fixing sys.mk to guard against
>>> recursive inclusion of __MAKE_CONF. bsd.port.mk is known to have
>>> this when using make(1) for do-build.
>>>
>>> Not that I mind shoving the issue under the carpet by using gmake.
> [...]
>>
>> Ah now there is a better solution :)
>
> It breaks non ports builds if the guard is propagated  via .MAKEFLAGS.
> And one no longer can .if/.ifdef (in make.conf) innards of ports.
>
>>
>> I'll see if we can get it in the tree.
>
> Nevermind, in case of lang/lua
>
>  1/ sys.mk sets CFLAGS= from make.conf
>  2/ Makefile adds -fPIC to CFLAGS
>  3/ bsd.port.mk copies CFLAGS to MAKE_ENV
>  4/ sys.mk sets CFLAGS from make.conf again,
>     `=' overrides CFLAGS from environment
>
> A simple make(1) build doesn't export CFLAGS
>
> # Makefile
> all:
>        @cd foo && $(MAKE)
>        @cd foo && CFLAGS='$(CFLAGS)' $(MAKE)
>
> # foo/Makefile
> all:
>        @echo $(CFLAGS)

So... can be worked around with using ?= in make.conf?

If that's the case then no code needs changing :)

Chris