Set a temporary environment ($PATH)

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 with VAR1=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.

As we all know, it is preferrable to integrate standard tools for a task like building your products instead of creating your own approach. The effort usually pays off in the long term.

That being said, a simple approach would be to define different environment files (e.g. build-phone.env) setting working directory, PATH, CC etc. for your different products and source your environment files interactively on demand:

. /path/to/build-phone.env
[your build commands]
. /path/to/build-watch.env
[your build commands]

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_project
make -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.

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/bash
ver=2.4.2
export TOP=/usr/local/python-$ver
export PATH=$TOP/bin:$PATH
export LD_LIBRARY_PATH=`newpath -n LD_LIBRARY_PATH -bd $TOP/lib $TOP/lib/gcc/i686-pc-linux-gnu/$ver`
if test -d $TOP
then
    exec $*
else
    echo no $TOP
    exit 1
fi

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 mingw32

BUILD_CC=${CC:-gcc}
unset CC
unset CXX

TARGET=`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 1
fi

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.