[MacPorts] #64009: pg cmake-1.1: add option to formally override build.cmd, for Make-type builds

[MacPorts]

#64009: pg cmake-1.1: add option to formally override build.cmd, for Make-type
builds
---------------------------+----------------------
  Reporter:  mascguy       |      Owner:  mascguy
      Type:  enhancement   |     Status:  assigned
  Priority:  Normal        |  Milestone:
 Component:  ports         |    Version:  2.7.1
Resolution:                |   Keywords:
      Port:  pg-cmake-1.1  |
---------------------------+----------------------

Comment (by mascguy):

 Replying to [comment:3 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 [comment:2 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?

-- 
Ticket URL: <https://trac.macports.org/ticket/64009#comment:4>
MacPorts <https://www.macports.org/>
Ports system for macOS