23ee2a7d62
Instead of defining a variable that is almost always based on CONFIGURE_ENV, just use CONFIGURE_ENV directly. This also matches the behavior of other ports that do not use autotools (so most ports can just worry about CONFIGURE_ENV). Additionally, the fact that we do not use ?= means we do not have problems if another file in Uses/ needs to set CONFIGURE_ENV (with CMAKE_ENV, the order of the arguments to USES would matter). Ports which set CMAKE_ENV have been adjusted accordingly. In most cases, CMAKE_ENV was just replaced with CONFIGURE_ENV, the exceptions being: * databases/sqliteman: CMAKE_ENV line removed; setting QMAKESPEC there has no effect on the build system. * devel/freeocl: CMAKE_ENV line removed; FREEOCL_CXX_COMPILER is already retrieved from the CMAKE_CXX_COMPILER variable in the build system. * graphics/openimageio: CMAKE_ENV line removed; setting Qt variables there has no effect on the build system. Reviewed by: makc Differential Revision: https://reviews.freebsd.org/D3403 |
||
---|---|---|
.. | ||
distinfo | ||
Makefile | ||
pkg-descr | ||
pkg-plist |