gmake and trace mode

[Joshua Root]

On 2019-2-2 12:59 , Ryan Schmidt wrote:
> 
> 
> 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?

Only if configure.pre_args is not modified by the portfile (removing the
trace) before setting cmake.generator. Maybe that never happens? But it
seems like a callback would be safer.

- Josh