svn commit: r296637 - in head: contrib/bmake contrib/bmake/mk contrib/bmake/unit-tests share/mk usr.bin/bmake

[Bryan Drewery]

On 3/11/2016 12:31 PM, Simon J. Gerraty wrote:
> Bryan Drewery <bdrewery at FreeBSD.org> wrote:
> 
>>> ~/git/freebsd # head usr.bin/bmake/Makefile
>>> # This is a generated file, do NOT edit!
>>> # See contrib/bmake/bsd.after-import.mk
>>
>> Is this still true? I have to rename MAKE_VERSION in
> 
> Yes it is still true.
> 
>> usr.bin/bmake/Makefile because it is colliding with the built-in
>> MAKE_VERSION breaking my upgrade checks in bsd.dep.mk when trying to
>> build the new bmake itself.
> 
> Sounds like you might have a bug.
> What is the specific issue?
> 

Older bmake (with default MAKESYSPATH=.../share/mk) running 'make
upgrade_checks' in top-level which builds latest bmake in usr.bin/bmake
which uses share/mk/bsd.dep.mk where I check MAKE_VERSION for .dinclude
support.  Since usr.bin/bmake/Makefile overrides MAKE_VERSION then the
check later in bsd.dep.mk fails because it thinks .dinclude is available
when it is not.

At least on older releases the make doesn't default MAKESYSPATH to
.../share/mk so it uses the installed /usr/share/mk which avoids the
problem, but only assuming someone didn't commit code anticipating a
release with a specific MAKE_VERSION like I almost did this week.

I renamed it to _MAKE_VERSION to avoid the problem in
usr.bin/bmake/Makefile.

-- 
Regards,
Bryan Drewery

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20160311/2fd51e6d/attachment.sig>