Continuum Analytics: Documentation

# Environment variables

## Dynamic behavior based on state of build process

There are times when you may want to process a single file in different ways at more than one step in the render -> build -> test flow of conda-build. Conda build sets the `CONDA_BUILD_STATE` environment variable during each of these phases. The possible values currently are `RENDER`, `BUILD`, and `TEST`. The `RENDER` state is set during evaluation of the meta.yaml file. The `BUILD` state is set during processing of the bld.bat or build.sh script files. Finally, the `TEST` state is set during the running of any `run_test` scripts, which also includes any commands defined in `meta.yaml` in the `test/commands` section. The CONDA_BUILD_STATE variable is undefined outside of these locations.

## Environment variables set during the build process

The following environment variables are set, both on Unix (build.sh) and on Windows (bld.bat) during the build process. (By default, these are the only variables available to your build script – unless otherwise noted, no variables are inherited from the shell environment in which you invoked `conda build`. See Inherited Environment Variables to override this behavior.)

`ARCH` | Either `32` or `64`, to specify whether the build is 32-bit or 64-bit. The value depends on the `ARCH` environment variable, and defaults to the architecture the interpreter running conda was compiled with
`CMAKE_GENERATOR` | The CMake generator string for the current build environment. On Unix systems, this is always “Unix Makefiles”. On Windows, it is generated according to the Visual Studio version activated at build time, e.g. “Visual Studio 9 2008 Win64”
`CONDA_BUILD=1` | Always set
`CPU_COUNT` | Number of CPUs on the system, as reported by `multiprocessing.cpu_count()`
`SHLIB_EXT` | The shared library extension
`DIRTY` | Set to 1 if –dirty flag passed to conda build command. May be used to skip parts of build script conditionally (downloads, extraction, other things that need not be repeated for faster iteration time when developing recipes)
`HTTP_PROXY` | Inherited from your shell environment.
`HTTPS_PROXY` | Inherited from your shell environment.
`LANG` | Inherited from your shell environment.
`MAKEFLAGS` | Inherited from your shell environment. May be used to set additional arguments to make, such as -j2, which will use 2 CPU cores to build your recipe.
`NPY_VER` | Numpy version building against (Set via –numpy arg or via CONDA_NPY environment variable.)
`PATH` | Inherited from your shell environment, and augmented with `$PREFIX/bin`
`PREFIX` | Build prefix where build script should install to
`PKG_BUILDNUM` | Build number of the package being built
`PKG_NAME` | Name of the package being built
`PKG_VERSION` | Version of the package being built
`PYTHON` | Path to Python executable in build prefix (note that Python is only installed in the build prefix when it is listed as a build requirement)
`PY3K` | `1` when Python 3 is installed in build prefix, else `0`
`R` | Path to R executable in build prefix (note that R is only installed in the build prefix when it is listed as a build requirement).
`RECIPE_DIR` | Directory of recipe
`SP_DIR` | Python’s site-packages location
`SRC_DIR` | Path to where source is unpacked (or cloned). If the source file is not a recognized file type (right now, `.zip`, `.tar`, `.tar.bz2`, `.tar.xz`, and `.tar`), this is a directory containing a copy of the source file
`STDLIB_DIR` | Python standard library location

When building “Unix-style” packages on Windows, which are then usually statically linked to executables, we do this in a special Library directory under the build prefix. The following environment variables are only defined in Windows:

`CYGWIN_PREFIX` | Same as `PREFIX`, but as a Unix-style path, e.g. `/cygdrive/c/path/to/prefix`
`LIBRARY_BIN` | `<build prefix>\Library\bin`
`LIBRARY_INC` | `<build prefix>\Library\include`
`LIBRARY_LIB` | `<build prefix>\Library\lib`
`LIBRARY_PREFIX` | `<build prefix>\Library`
`SCRIPTS` | `<build prefix>\Scripts`
`VS_MAJOR` | The major version number of the Visual Studio version activated within the build, e.g. `9`
`VS_VERSION` | The version number of the Visual Studio version activated within the build, e.g. `9.0`
`VS_YEAR` | The release year of the Visual Studio version activated within the build, e.g. `2008`

On non-Windows (Linux and OS X), we have:

`HOME` | Standard `$HOME` environment variable
`PKG_CONFIG_PATH` | Path to `pkgconfig` directory

On OS X, we have:

`CFLAGS` | `-arch` flag
`CXXFLAGS` | Same as `CFLAGS`
`LDFLAGS` | Same as `CFLAGS`
`MACOSX_DEPLOYMENT_TARGET` | Same as the Anaconda Python. Currently `10.6`
`OSX_ARCH` | `i386` or `x86_64`, depending on Python build

On Linux, we have:

`LD_RUN_PATH` | `<build prefix>/lib`

### Git Environment Variables

When the source is a git repository, specifying the source either with `git_url` or `path`, the following variables are defined:

`GIT_BUILD_STR` | a string that joins `GIT_DESCRIBE_NUMBER` and `GIT_DESCRIBE_HASH` by an underscore
`GIT_DESCRIBE_HASH` | the current commit short-hash as displayed from `git describe --tags`
`GIT_DESCRIBE_NUMBER` | string denoting the number of commits since the most recent tag
`GIT_DESCRIBE_TAG` | string denoting the most recent tag from the current commit (based on the output of `git describe --tags`)
`GIT_FULL_HASH` | a string with the full SHA1 of the current HEAD

These can be used in conjunction with templated meta.yaml files to set things like the build string based on the state of the git repository.

### Mercurial Environment Variables

When the source is a mercurial repository, the following variables are defined:

`HG_BRANCH` | string denoting the presently active branch
`HG_BUILD_STR` | a string that joins `HG_NUM_ID` and `HG_SHORT_ID` by an underscore
`HG_LATEST_TAG` | string denoting the most recent tag from the current commit
`HG_LATEST_TAG_DISTANCE` | string denoting number of commits since most recent tag
`HG_NUM_ID` | string denoting the revision number
`HG_SHORT_ID` | string denoting the hash of the commit

### Inherited Environment Variables

Other than those mentioned above, no variables are inherited from the environment in which you invoked `conda build`. You can choose to inherit additional environment variables by adding them to `meta.yaml`:

    build:
      script_env:
       - TMPDIR
       - LD_LIBRARY_PATH # [linux]
       - DYLD_LIBRARY_PATH # [osx]

If an inherited variable was missing from your shell environment, it will remain unassigned, but a warning will be issued noting that it has no value assigned.

NOTE: Inheriting environment variables like this can make it difficult for others to reproduce binaries from source with your recipe. This feature should be used with caution or avoided altogether.

## Environment variables that affect the build process

`CONDA_PY` | Should be `27`, `34`, or `35`. This is the Python version used to build the package.
`CONDA_NPY` | This is the NumPy version used to build the package, such as `19`, `110`, or `111`.
`CONDA_PREFIX` | This is the path to the conda environment used to build the package, such as `/path/to/conda/env`. Useful to pass as the environment prefix parameter to various conda tools, usually labeled `-p` or `--prefix`.

## Environment variables to set build features

Three environment variables are inherited from the process running `conda build`. These three variables control Features as defined in The meta.yaml file.

`FEATURE_NOMKL` | Adds the `nomkl` feature to the built package. | Accepts `0` for off and `1` for on.
`FEATURE_DEBUG` | Adds the `debug` feature to the built package | Accepts `0` for off and `1` for on.
`FEATURE_OPT` | Adds the `opt` feature to the built package | Accepts `0` for off and `1` for on.

## Environment variables that affect the test process

All of the above environment variables are also set during the test process, except with the test prefix instead of the build prefix everywhere.