[MacPorts] #54853: Using configure.ccache=yes on the commandline overrides portfile configure.ccache=no

[MacPorts]

#54853: Using configure.ccache=yes on the commandline overrides portfile
configure.ccache=no
----------------------+--------------------
  Reporter:  RJVB     |      Owner:
      Type:  defect   |     Status:  closed
  Priority:  Normal   |  Milestone:
 Component:  base     |    Version:
Resolution:  invalid  |   Keywords:
      Port:           |
----------------------+--------------------

Comment (by RJVB):

 Then there is an oversight in the intended behaviour, IMVHO.  Being able
 to override one way doesn't make it impossible to override the other way
 round, nor does it mean that should be the case.

 I've taken a quick look in portutil.tcl, but it's not yet clear to me
 where one would implement a -force feature that would allow a Portfile to
 override a commandline setting but apparently that wouldn't have the
 intended effect anyway (see the `-append` observation below).

 Take configure.optflags, configure.cflags and family, options variables
 that don't have equivalents in macports.conf. Users should be (and are)
 able to fine-tune builds with generally harmless optional optflags like
 -march=native and/or -g . Ports on the other hand are able to detect and
 filter out options known to cause issues (a 32bit build might want to
 filter out `-mdynamic-no-pic` for instance). Maybe not a big deal when
 you're building a single port, but what if you're doing a `port -s upgrade
 outdated` or `port -s install qt5-creator` more or less from scratch, with
 safe custom compiler options that should improve overall performance, and
 the 10th or so of a much larger number of builds fails despite the best
 attempts of its author to avoid such failures?

 There's another aspect to the oversight: one could (would) expect that
 `configure.optflags-append -foo` always appends the (possible crucial)
 arguments, be it to the default optflags or those set on the commandline.

 It was strongly suggested during the review of my cmake-1.1 PG that I use
 options variables for settings like the CMake generator (make vs. ninja).
 Most cmake projects can use either of those generators, but some don't
 work well with ninja. It really annoys me that I wasn't aware one can
 specify options variables on the commandline at the time; I probably
 wouldn't have accepted to use one for at least certain of the cmake
 options. It's just not my idea of how to code.

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