Creating conan packages to install dev tools

Conan 1.0 introduced two new settings, os_build and arch_build. These settings represent the machine where Conan is running, and are important settings when we are packaging tools.

These settings are different from os and arch. These mean where the built software by the Conan recipe will run. When we are packaging a tool, it usually makes no sense, because we are not building any software, but it makes sense if you are cross building software.

We recommend the use of os_build and arch_build settings instead of os and arch if you are packaging a tool involved in the building process, like a compiler, a build system etc. If you are building a package to be run on the host system you can use os and arch.

A Conan package for a tool follow always a similar structure, this is a recipe for packaging the nasm tool for building assembler:

import os
from conans import ConanFile
from conans.client import tools

class NasmConan(ConanFile):
    name = "nasm"
    version = "2.13.01"
    license = "BSD-2-Clause"
    url = ""
    settings = "os_build", "arch_build"
    build_policy = "missing"
    description="Nasm for windows. Useful as a build_require."

    def configure(self):
        if self.settings.os_build != "Windows":
            raise Exception("Only windows supported for nasm")

    def nasm_folder_name(self):
        return "nasm-%s" % self.version

    def build(self):
        suffix = "win32" if self.settings.arch_build == "x86" else "win64"
        nasm_zip_name = "" % (self.nasm_folder_name, suffix)""
                       "%s/%s/%s" % (self.version, suffix, nasm_zip_name), nasm_zip_name)
        self.output.warn("Downloading nasm: "
                         "/%s/%s/%s" % (self.version, suffix, nasm_zip_name))

    def package(self):
        self.copy("*", dst="", keep_path=True)
        self.copy("license*", dst="", src=self.nasm_folder_name, keep_path=False, ignore_case=True)

    def package_info(self):"Using %s version" % self.nasm_folder_name)
        self.env_info.path.append(os.path.join(self.package_folder, self.nasm_folder_name))
  • The configure method discards some combinations of settings and options, by throwing an exception. In this case this package is only for Windows.
  • The build method downloads the appropriate file and unzips it.
  • The package method is copying all the files from the zip to the package folder.
  • The package info is using the self.env_info to append to the environment variable “path” the package’s bin folder.

This package has only 2 differences from a regular conan library package:

  • The source method is missing. That’s because when you compile a library, the source code is always the same for all the generated packages, but in this case we are downloading the binaries, so we do it in the build method to download the appropriate zip file according to each combination of settings/options. Instead of actually building the tools, we just download them. Of course, if you want to build it from source, you can do it too, by creating your own package recipe.
  • The package_info method uses the new “self.env_info” object. With “self.env_info” the package can declare environment variables that will be set automatically before the build, package, source and imports methods of the conanfile requiring this package. This is a convenient method to use these tools without having to mess with the system PATH.

Using the tool packages in other recipes

The self.env_info variables will be automatically applied when you require a recipe that declares them. For example, take a look at the MinGW recipe (

class MingwInstallerConan(ConanFile):
    name = "mingw_installer"

    build_requires = "7z_installer/1.0@conan/stable"

    def build(self):
        keychain = "%s_%s_%s_%s" % (str(self.settings.compiler.version).replace(".", ""),

        files = {
           ...        }[keychain], "file.7z")"7z x file.7z")


We are requiring a build_require to another package, the 7z_installer, which will be used to unzip the mingw installers (with 7z compression).

In the build method we download the appropriate MinGW installer. The 7z executable will be in the PATH, because the 7z_installer dependency declares the “bin” folder in its “package_info” method.

Using the tool packages in your system

You can use the virtualenv generator to get the requirements applied in your system.

For example, if you are working in Windows, with MinGW and CMake.

  1. Create a separate folder from your project, this folder will handle our global development environment.
mkdir my_cpp_environ
cd my_cpp_environ
  1. Create a ‘conanfile.txt’ file:


Note that you can adjust the options and retrieve a different configuration of the required packages, or leave them unspecified in the file and pass them as command line parameters.

  1. Install them:
$ conan install .
  1. Activate the virtual environment in your shell:
$ activate
  1. Check that the tools are in the path:
(my_cpp_environ)$ gcc --version

> gcc (x86_64-posix-seh-rev1, Built by MinGW-W64 project) 4.9.2

 Copyright (C) 2014 Free Software Foundation, Inc.
 This is free software; see the source for copying conditions.  There is NO

(my_cpp_environ)$ cmake --version

> cmake version 3.10

  CMake suite maintained and supported by Kitware (
  1. You can deactivate the virtual environment with the “deactivate.bat” script
(my_cpp_environ)$ deactivate