svn commit: r381980 - head

[Bryan Drewery]

On 3/22/2015 11:51 PM, Bryan Drewery wrote:
> 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.
> 

Actually I've hit a few blockers that are showing me this is just not
going to work. I'm going a different route with using bmake. I think
there are a lot of MAKE->MAKE_CMD cleanup to still do but that it it not
as relevant for my use case now.

-- 
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/20150323/f212e547/attachment.sig>