Why USES=fortran do not respect USE_GCC variable?

When I build math/py-numpy, for example, it does not respect USE_GCC variable from command line, but uses GCC_DEFAULT instead for a ersion of gfortran to use.

Is there a reason for that? Any way to bypass it (other than default version for GCC in make.conf)?
 
I'm not sure I entirely understand what you mean, but USE_GCC is meant to be used in a port's Makefile, not by the user. It's the way a port should set dependencies on GCC and also allows the maintainer to specify which GCC versions are acceptable.

If this is about picking a default GCC version that's used when the port requires "any" version, you should use DEFAULT_VERSIONS instead, e.g. DEFAULT_VERSIONS+= gcc=11.

Never set GCC_DEFAULT manually, that's an internal variable of the default-versions mechanism.

Why would you need a way to "bypass" that? Because it's "global"? Well, for most default versions, using different ones for different ports will just break things. But you can do so if you want, e.g.:
Code:
.if ${.CURDIR:M*/math/py-numpy}
DEFAULT_VERSIONS+= gcc=11
.endif
 
As far as I know, it is possible to use USE_GCC from command line when some port is building manually from ports' tree.

For example, I want to try to use gcc13-devel for a specific port, not changing default gcc version. (Which cannot be set to 13-devel, by the way.) Most of ports do respect USE_GCC value from a command line for that purpose, choosing gcc13 compiler and setting some other building variable, but not when it has USES=fortran in its' Makefile.

To use DEFAULT_VERSIONS manually is strictly unrecommended, as I can see it, only via make.conf.
 
As far as I know, it is possible to use USE_GCC from command line when some port is building manually from ports' tree.
It might be "possible", but it's just plain wrong and very likely to break things. (if it "works", you override the port maintainer's choice of acceptable GCC versions. This variable is for use in a port Makefile only.)
To use DEFAULT_VERSIONS manually is strictly unrecommended, as I can see it, only via make.conf.
Just as unrecommended as the construct setting it for an individual port I posted above. The reason is that things typically break when using different default versions for different ports.
 
Back
Top