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