The benefit of using a package manager like conan is, in addition to many other advantages, manage your project dependencies. You can build your project even in different computers and with different operating systems just running
conan install command again.
But that’s not completely true, you usually need some tools like a compiler and maybe a separate build system to build your project. So, if you change your computer you will need to setup your build tools with the system package manager (apt, yum…) or downloading the installers, etc.
In the latest 0.11 release, we’ve introduced some minor changes to conan to try to help our users to reproduce their environments easily. We don’t pretend to replace the current applications managers; yum, apt, brew…etc, are GREAT tools, but maybe conan users can benefit of custom and easy installers for the applications that they use to build software.
Conan has a new generator called
virtualenv, inspired in python virtual environments that we really love. This generator can be activated like any other in the [generators] section of your conanfile, and will generate two files:
If we run the activate script, conan will set our current shell environment variables with the values that the installed packages declare. The most common usage would be setting the PATH environment variable, so tools can be easily executed.
Let’s see an example. Lets suppose we are working on a Windows machine, and we want to build and test a project with different versions of MinGW and CMake. So we can do:
Create a separate folder from your project. This folder will handle our development environment.
Now, create a
In this file we are requiring two packages, one is the MinGW installer and the other is a CMake installer. The “0.1” version is the version of the installer recipe, not the MinGW nor CMake tools. If you want to create your own recipes matching the tool version, you can, but in this way we are able to handle many MinGW and CMake versions just with the same recipes. Later we will se how can we install those different versions.
Install the packages:
Once the tools have been installed, you can activate the virtual environment in your shell:
Check that everything is working and the tools are in the path:
You can now deactivate the virtual environment with the
The same can be done (with CMake, because MinGW is just for Windows), in Linux/OSx. If you are a Conan user you will know that every package depends on the settings and options. So, we can change the available options to get a different MinGW version easily.
Let’s take a look to the MinGW installer recipe. Go to (https://www.conan.io/source/mingw_installer/0.1/lasote/testing) and click in “conanfile.py” tab.
We have available these options:
By default we are installing MinGW 4.9 with posix thread support and sjlj exceptions. But we can install MinGW with other options:
Edit your conanfile.txt:
Remember to deactivate the previous virtual environment:
And install again:
You can also pass the options in the command line instead of specifying them in the conanfile.txt file
Activate the virtual environment and check that the tools have changed:
You can share this
conanfile.txt with your team and share this way the development environment!
How can I create my own tool packages?
If you want to create conan packages for any tool it is easy, specially if you are already familiar creating conan packages.
Let’s see how the conan CMake recipe is done:
The config method is avoiding some setting/options combinations throwing an exception. The build method is downloading the right CMake file and unzipping 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 have only 2 different things than 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 different zip file for each settings/option combination. Instead of really building the tools, we are just downloading them. Of course if you want to build it from source, you can do it too, create your own package recipe
The package_info method use the new
With “self.env_info” the package can declare environment variables that will be setted with the
self.env_info variable can also be useful if a package tool depends on another tool.
Take a look to the MinGW conanfile.py recipe:
In the config method we are adding a require to another package, the 7z_installer that will be used to unzip the mingw installers (with 7z compression).
In the build method we are downloading the right MinGW installer and using the helper
ConfigureEnvironment. This helper will provide us a string with a command to set the environment variables. That means that the 7z executable will be in the path, because the 7z_installer dependency declares the
bin folder in its
In the package_info method we are declaring CC and CXX variables, used by CMake, autotools etc, to locate the compiler for C/C++ respectively.
Also we are appending to
path variable the bin folder, so we can invoke gcc, g++, make and other tools in the command line using the virtualenv generator when we execute the
The possibilities of these features are even larger. They are very useful for example in CI environments. Also, if you want to avoid copying shared (.dlls, .dylib) libraries to the project binary directory (which can be done with the
imports feature), you can make packages to add them to the environment PATH variable, so consumers can use it to easily find the correct shared libraries for multiple different versions and settings.
What do you think? Do you like this feature? What tools would you like to have as a conan package? Use our whislist and tell us what is your development environment!