svn commit: r381980 - head

[Bryan Drewery]

On 3/22/2015 11:08 PM, Bryan Drewery wrote:
> Author: bdrewery
> Date: Mon Mar 23 04:08:27 2015
> New Revision: 381980
> URL: https://svnweb.freebsd.org/changeset/ports/381980
> QAT: https://qat.redports.org/buildarchive/r381980/
> 
> Log:
>   Undocument BSDMAKE from r381977 as I have thought of a better way and will
>   likely revert it.
>   
>   With hat:	portmgr
> 
> Modified:
>   head/CHANGES
> 
> Modified: head/CHANGES
> ==============================================================================
> --- head/CHANGES	Mon Mar 23 04:07:08 2015	(r381979)
> +++ head/CHANGES	Mon Mar 23 04:08:27 2015	(r381980)
> @@ -10,13 +10,6 @@ in the release notes and/or placed into 
>  
>  All ports committers are allowed to commit to this file.
>  
> -20150322:
> -  AUTHOR: bdrewery at FreeBSD.org
> -
> -  There is now a BSDMAKE that can be overriden for the location of
> -  /usr/bin/make. It is a safer alternative to overriding MAKE_CMD which
> -  will be force reset for gmake/fmake/scons ports.
> -
>  20150319:
>    AUTHOR: bdrewery at FreeBSD.org
>  
> 

I feel the need to define BSDMAKE still but don't like that it is not
just MAKE_CMD since that is what has been advertised for so long.

MAKE_CMD currently has 2 uses. Both the default /usr/bin/make location
and the make that is used to interact with a port's distribution
Makefile. When using USES=gmake for example MAKE_CMD becomes gmake.
There then is no way to define what the default make was (/usr/bin/make)
if it is still needed.

From sometime last year until r381976 a user setting MAKE_CMD would not
be able to build gmake/scons/fmake ports.

What I am trying to do is interact with the ports tree with bmake but
build ports with fmake. Bmake does not work with the /usr/share/mk on
8.4/9.3 but it works fine with the ports tree. Any actual Makefile with
real object targets it encounters hits a 'dirsyntax' error and fails. So
I am trying to ensure that ports are respecting MAKE_CMD and building
with my override of /usr/bin/fmake since I have made /usr/bin/make into
bmake. This idea may grow into a bootstrapped bmake so 8.4 does not
instantly break on EOL day. I don't know if I will take it that far.

This is why I have added BSDMAKE and switched to it in the qemu ports in
r381978 since they have USES=gmake and get a MAKE_CMD=gmake. MAKE is
bmake in my use. I insist that using ${MAKE} to build a port's
distribution files is just fundamentally wrong; it should only be used
to interact recursively with the framework. This port was nice enough to
spell out that it needs a real bsd make to build. It may even work with
gmake at this point but I did not test.

Incidentally I have been finding a lot interesting bugs with MAKE_CMD
usage. Some ports claim to need gmake but are accidentally using bsdmake
in the middle of their build. It has just worked by accident. I imagine
that fixing these to properly use MAKE_CMD (hence gmake) will improve
parallel builds as well.

So my alternative idea for BSDMAKE was to mass replace MAKE_CMD with
_MAKE_CMD in ports and then keep MAKE_CMD to mean /usr/bin/make. I'm not
sure which route should be taken.

-- 
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-ports-all/attachments/20150322/d93dd2db/attachment.sig>