Opened 3 years ago
Last modified 8 months ago
#64009 assigned enhancement
cmake-1.1 portgroup: 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 (9)
comment:1 Changed 3 years ago by RJVB (René Bertin)
comment:2 Changed 3 years ago by 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.
comment:3 follow-up: 4 Changed 3 years 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 follow-up: 5 Changed 3 years 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 setbuild.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 Changed 3 years ago by RJVB (René Bertin)
Replying to mascguy:
Theoretically, a port could depend on
gmake
for some other purpose, without overridingbuild.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 3 years ago by Christopher Nielsen <mascguy@…>
comment:7 Changed 2 years 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.
comment:8 Changed 8 months ago by kencu (Ken)
Summary: | pg cmake-1.1: add option to formally override build.cmd, for Make-type builds → cmake-1.1 portgroup: add option to formally override build.cmd, for Make-type builds |
---|
comment:9 Changed 8 months ago by RJVB (René Bertin)
Replying to mascguy:
Presently, portgroup
cmake-1.1
is hard-coded to assume the use of macOSmake
, for Make-type builds. However, that precludes the use ofgmake
.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.
Alternatively, the PG could just use
gmake
unconditionally if it's available. Ports that require it can then simply ensure that viadepends_build
(which they already do, presumably).Somewhere I find that solution more elegant
gmake
, or does it (is there any port that does NOT build with gmake instead of make)?cmake.make
variable but no equivalentcmake.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.