gmake and trace mode

Ryan Schmidt ryandesign at macports.org
Sat Feb 2 01:59:15 UTC 2019



On Feb 1, 2019, at 19:53, Joshua Root wrote:

> On 2019-2-2 12:21 , Ryan Schmidt wrote:
> 
>> On Feb 1, 2019, at 18:52, Joshua Root wrote:
>> 
>>> On 2019-2-2 11:16 , Joshua Root wrote:
>>>> On 2019-2-2 11:06 , Ryan Schmidt wrote:
>>>>> 
>>>>> 
>>>>> On Feb 1, 2019, at 18:04, Joshua Root wrote:
>>>>> 
>>>>>> On 2019-2-2 10:16 , Ryan Schmidt wrote:
>>>>>>> If the gmake port is installed, then ports that use make will fail in trace mode, unless the port declares a dependency on the gmake port.
>>>>>> 
>>>>>> That doesn't appear to be true in the general case (I just tried a
>>>>>> couple ports that didn't fail). How do ports know to try gmake if it's
>>>>>> being hidden by trace mode?
>>>>> 
>>>>> I've encountered it myself with another port. Maybe it's only cmake-using ports.
>>>> 
>>>> Yes, that seems to be it. Still not sure how cmake is deciding to use
>>>> gmake when it should appear not to exist, but we should convince it to
>>>> use the ${build.cmd} specified by base instead.
>>> 
>>> CMAKE_MAKE_PROGRAM seems to be the required variable. I'll leave setting
>>> it correctly in the mess that is cmake-1.1 to others.
>> 
>> Thanks for finding that! Looks like your fix from cmake-1.0 also works in 1.1 so I added it there too.
> 
> It only works when using default settings -- cmake-1.1 allows using
> ninja in which case this would not be correct.
> 
> See <https://cmake.org/cmake/help/v3.13/variable/CMAKE_MAKE_PROGRAM.html>

"proc cmake::handle_generator" sets build.cmd to "make" or "ninja". So maybe that's sufficient?



More information about the macports-dev mailing list