Using configure.ccache=yes on the commandline overrides portfile configure.ccache=no

[RJVB (René Bertin)]

I just discovered that using configure.ccache=yes on the commandline to use the built-in ccache support on a punctual basis can break the build of ports that are incompatible with this feature and that thus set configure.ccache no in their portfile (or in the case of ports using CMake, in the portgroup).

I can see how commandline foo=baz specifications need to override the value set via

options foo
default foo bar

but there are clearly cases where this shouldn't happen when a value is set explicitly, even if that value is equal to the default.

Maybe add a -force option to options variable, so the aforementioned ports can force a feature setting instead of having to detect and raise errors?

configure.ccache -force no

[raimue (Rainer Müller)]

This is the intended behavior. You can override many Portfile options that way.

You need to override the setting that is used in macports.conf instead:

sudo port build foo configureccache=yes

[RJVB (René Bertin)]

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.

[RJVB (René Bertin)]

Cf. ​https://github.com/RJVB/macstrop/commit/c791f4ba8a291e067351a02cd3a7bd14ab2f383b