cmake-1.1 portgroup: add option to formally override build.cmd, for Make-type builds

[mascguy (Christopher Nielsen)]

Presently, portgroup cmake-1.1 is hard-coded to assume the use of macOS make, for Make-type builds. However, that precludes the use of gmake.

Add a formal override, allowing ports to specify the value for build.cmd for that case.

[RJVB (René Bertin)]

Alternatively, the PG could just use gmake unconditionally if it's available. Ports that require it can then simply ensure that via depends_build (which they already do, presumably).

Somewhere I find that solution more elegant

• I don't think the standard/system make has anything over gmake, or does it (is there any port that does NOT build with gmake instead of make)?
• It doesn't introduce an additional control variable
• No one gets to wonder why there's a cmake.make variable but no equivalent cmake.ninja ;)

Using a cmake.make control variable could be elegant too, but you'd probably want it to pull in port:gmake as a build dep, or remove it again if ever a port sees a reason to switch the build command back FROM gmake. That seems a tad much complexity if you can just test if gmake is availabe instead.

[ryandesign (Ryan Carsten Schmidt)]

The "standard/system make" and gmake are both GNU make, just potentially different versions of them.

If the portgroup doesn't allow the portfile to specify the use of gmake by setting build.cmd ${prefix}/bin/gmake as is customary, I would indeed consider that to be a bug in the portgroup.

I don't see any need to introduce a new cmake portgroup variable for this. The cmake portgroup merely needs to respect the portfile's choice of build.cmd, if it does not already do that.

[RJVB (René Bertin)]

There is no caching of the original build.cmd value; it is simply set to make. This is done in the setter routine for cmake.generator and if that routine is also called for the default value of that variable, then, indeed, the port's choice of make flavour will get lost.

Is it possible to guarantee that we'll always restore build.cmd to the value set by the Portfile. We could cache the build.cmd value, but the Portfile *could* for some reason set the cmake generator first to ninja and then back to make and set build.cmd set to, say, bsdmake, BETWEEN those two generator changes? Sounds like it would require a complicated bit of code unless we either call that "operator error" or introduce a dedicated variable...

I still stand by my suggestion to use gmake instead of plain make if available - if of course there are no counterindications nor yet other alternative "make" (other than bsdmake, which doesn't appear to be used with cmake-based ports for now).

[mascguy (Christopher Nielsen)]

Replying to RJVB:

Is it possible to guarantee that we'll always restore build.cmd to the value set by the Portfile. We could cache the build.cmd value, but the Portfile *could* for some reason set the cmake generator first to ninja and then back to make and set build.cmd set to, say, bsdmake, BETWEEN those two generator changes? Sounds like it would require a complicated bit of code unless we either call that "operator error" or introduce a dedicated variable...

Yes, that's why my preference is a formal PG option, to eliminate any such headaches.

I still stand by my suggestion to use gmake instead of plain make if available - if of course there are no counterindications nor yet other alternative "make" (other than bsdmake, which doesn't appear to be used with cmake-based ports for now).

Theoretically, a port could depend on gmake for some other purpose, without overriding build.cmd to use it. I can't imagine a need for such a scenario, apart from a rare case. But in the interest of eliminating any possible ambiguity or side-effects, I'd prefer a formal option.

Replying to ryandesign:

I don't see any need to introduce a new cmake portgroup variable for this. The cmake portgroup merely needs to respect the portfile's choice of build.cmd, if it does not already do that.

I'm sure you're already aware, but the challenge here is that the CMake 1.1 portgroup forcibly changes build.cmd as appropriate [depending on the build type]. So it almost sounds like a chicken-and-egg issue, at least for the Make case: Should the portgroup respect what build.cmd is currently set to, or forcibly override it as done currently?

My main concern is ensuring that the PG properly utilizes what's specified by the port - again, only for the Make case - with no possible ambiguity. And specifying the desired choice via a formal PG option, would avoid any such issues. (Per the earlier comments from Rene, above.)

Thoughts?

[RJVB (René Bertin)]

Replying to mascguy:

Theoretically, a port could depend on gmake for some other purpose, without overriding build.cmd to use it. I can't imagine a need for such a scenario, apart from a rare case. But in the interest of eliminating any possible ambiguity or side-effects, I'd prefer a formal option.

My suggestion would circumnvent any such ambiguity, by simply using the newest/most capable make command. Base could do this too btw, and note that this is also what happens when users put a symlink make -> $prefix/bin/gmake somewhere ahead in the $PATH that build commands see.

[Christopher Nielsen <mascguy@…>]

In 663bed1e4938007edf920214d6554e76385a32dc/macports-ports (master):

retdec/retdec-devel: use full path to gmake
See: #63999

• Also revert to cmake-1.0 portgroup, due to outstanding issue:

See: #64009

[RJVB (René Bertin)]

I just tested an idea. The CMake 1.1 PG sets build.cmd in the callback for cmake.generator. IOW, you set the generator, build.cmd is set to the PG's default ... and you can then override that setting at liberty. In my quick test this also works when you do not set cmake.generator but only build.cmd. A priori that is because the generator callback isn't called for the default cmake.generator setting.

[RJVB (René Bertin)]

Replying to mascguy:

Presently, portgroup cmake-1.1 is hard-coded to assume the use of macOS make, for Make-type builds. However, that precludes the use of gmake.

Add a formal override, allowing ports to specify the value for build.cmd for that case.

There probably is rarely a need to change the command used for Ninja builds, but still, on 2nd thought the cleanest way to address this issue would be to have cmake.make_cmd and cmake.ninja_cmd (or equivalent) options with defaults set the current hardwired commands.

Is there an actual case where this is required? With CMake, Makefiles are generated from scratch, not from automake templates that could include features not supported by the system make command. IOW, it would take a pretty complex (and probably a "hybrid") build system to run into such features, as long as CMake itself doesn't use them.

EDIT: In fact I see more use of this kind of configurability with the Ninja generator. The official ninja is pretty aggressive and hard to tame in terms of the number of CPUs it will try to use, which is why many people replace it with samu (samurai). I have a port for that which provides $prefix/bin/ninja and is thus mutually exclusive with port:ninja. I haven't run into a single case where samu is not a fully functional drop-in replacement, and it certainly is less resource hungry in practise. But it does lack certain ninja features that a port might wish to use.