Uses/cmake.mk: Replace CMAKE_ENV with CONFIGURE_ENV.

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

1 files changed, 1 insertions, 1 deletions

diff --git a/comms/gnuradio/Makefile b/comms/gnuradio/Makefile
index 37c1e67ee84b..a54c3fc7e42b 100644
--- a/comms/gnuradio/Makefile
+++ b/comms/gnuradio/Makefile
@@ -35,7 +35,7 @@ RUN_DEPENDS:=	${BUILD_DEPENDS}
 
 USES=		cmake:outsource iconv perl5 python:2.7 shebangfix
 SHEBANG_FILES=	grc/freedesktop/grc_setup_freedesktop.in
-CMAKE_ENV+=	LD_PRELOAD="${GCC_LIBS}/libstdc++.so:${GCC_LIBS}/libgcc_s.so.1"
+CONFIGURE_ENV+=	LD_PRELOAD="${GCC_LIBS}/libstdc++.so:${GCC_LIBS}/libgcc_s.so.1"
 CMAKE_ARGS+=	-DSWIG_EXECUTABLE:STRING="${LOCALBASE}/bin/swig2.0"
 CMAKE_ARGS+=	-DICONV_PREFIX:STRING="${ICONV_PREFIX}" \
 		-DICONV_LIB:STRING="X${ICONV_LIB}" \