Set a temporary environment ($PATH)

When I have several variables to set, I write a wrapper script which I then use as a prefix to the command that I want to modify. That lets me use the prefix either

• applying to a single command, such as make, or
• initializing a shell, so that subsequent commands use the altered settings.

I use wrappers for

• setting compiler options (such as clang, to set the CC variable, making configure scripts "see" it as the chosen compiler),
• setting locale variables, to test with POSIX C versus en_US versus en_US.UTF-8, etc.
• testing with reduced environments, such as in cron.

Each of the wrappers does what is needed to identify the proper PATH, LD_LIBRARY_PATH, and similar variables.

For example, I wrote this ad hoc script about ten years ago to test with a local build of python:

#!/bin/bashver=2.4.2export TOP=/usr/local/python-$verexport PATH=$TOP/bin:$PATHexport LD_LIBRARY_PATH=`newpath -n LD_LIBRARY_PATH -bd $TOP/lib $TOP/lib/gcc/i686-pc-linux-gnu/$ver`if test -d $TOPthen    exec $*else    echo no $TOP    exit 1fi

and used it as with-python-2.4.2 myscript.

Some wrappers simply call another script.For example, I use this wrapper around the configure script to setup variables for cross-compiling:

#!/bin/sh# $Id: cfg-mingw,v 1.7 2014/09/20 20:49:31 tom Exp $# configure to cross-compile using mingw32BUILD_CC=${CC:-gcc}unset CCunset CXXTARGET=`choose-mingw32`if test -n "$TARGET"then    PREFIX=    test -d /usr/$TARGET && PREFIX="--prefix=/usr/$TARGET"    cfg-normal \            --with-build-cc=$BUILD_CC \            --host=$TARGET \            --target=$TARGET \            $PREFIX "$@"else    echo "? cannot find MinGW compiler in path"    exit 1fi

where choose-mingw32 and cfg-normal are scripts that (a) find the available target name for the cross-compiler and (b) provide additional options to the configure script.

Others may suggest shell aliases or functions. I do not use those for this purpose because my command-line shell is usually tcsh, while I run these commands from (a) other shell scripts, (b) directory editor, or (c) text-editor. Those use the POSIX shell (except of course, for scripts requiring specific features), making aliases or functions of little use.

You can create an individualized environment for a particular command invocation:

VAR1=val1 VAR2=val2 VAR3=val3 make

I find this cleaner than doing:

   export VAR1=val1   export VAR2=val2   export VAR3=val3   make

unless you're in a wrapper script and maybe even then as withVAR1=val1 VAR2=val2 VAR3=val3 make the VAR variables will be whatever they were before the make invocation (including but not limited to unexported and nonexistent).

Long lines is a non-issue, you can always split it across several lines:

VAR1=val1\VAR2=val2\VAR3=val3\make

You can set up environment variables like this for any Unix command.The shell will all set it up.Some applications (such as make or rake) will modify their environment based on arguments that look like variable definitions (see prodev_paris's answer), but that depends on the application.

Is it better to use the environment instead of custom makefiles to set a build configuration?

The best practice for build systems is to not depend on any environment variables at all. So that nothing more is necessary to build your project than:

git clone ... my_projectmake -C my_project

Having to set environment variables is error prone and may lead to inconsistent builds.

How to properly adjust existing environment variables?

You may not need to adjust those at all. By using complete paths to tools like compilers you disentangle your build system from the environment.