Opened 13 months ago

Last modified 6 months ago

#64009 assigned enhancement

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

Reported by: mascguy (Christopher Nielsen) Owned by: mascguy (Christopher Nielsen)
Priority: Normal Milestone:
Component: ports Version: 2.7.1
Keywords: Cc: RJVB (René Bertin)
Port: pg-cmake-1.1

Description

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.

Change History (7)

comment:1 Changed 13 months ago by 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.

comment:2 Changed 13 months ago by ryandesign (Ryan 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.

comment:3 Changed 13 months ago by 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).

comment:4 in reply to:  3 ; Changed 13 months ago by 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?

comment:5 in reply to:  4 Changed 13 months ago by 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.

comment:6 Changed 13 months ago by 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

comment:7 Changed 6 months ago by 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.

Note: See TracTickets for help on using tickets.