This section summarizes some possible layouts and workflows while using conan together with other tools as an end-user, i.e. installing and consuming existing packages. For creating your own packages, have a look at the Packaging section.
In both cases, the recommended approach is to have a conanfile (either .py or .txt) at the root of your project.
The single configuration is simple. It is the one that has been used so far for the examples and
tutorials. In Getting started, we ran the
conan install .. command
build folder and the
conanbuildinfo.cmake files were
generated there. The build folder is temporary, you should exclude it from version control, so those
temporary files are excluded too.
Out-of-source builds are also supported. Let’s make a simple example:
$ git clone https://github.com/memsharded/example-hello.git $ conan install ./example-hello --build=missing --install-folder example-hello-build
So the layout will be:
example-hello-build conaninfo.txt conanbuildinfo.txt conanbuildinfo.cmake example-hello conanfile.txt CMakeLists.txt # If using cmake, but can be Makefile, sln... main.cpp
Now you are ready to build:
$ cmake ../example-hello -G "Visual Studio 14 Win64" //or other generator $ cmake --build . --config Release $ ./bin/greet
We have created a separate build configuration of the project, without affecting at all the original source directory. The benefit is that we can experiment freely, and even erase it and create a new build with a new configuration with different settings, if needed:
$ cd example-hello-build $ rm -rf * $ conan install ../example-hello -s compiler="<other compiler>" --build=missing $ cmake ../example-hello -G "<other generator>" $ cmake --build . --config Release
You can also manage different configurations, in-source or out of source, and you can switch between
them without taking the extra step of re-issuing the
conan install command (even though this is
not a speed-related issue, since the second time
conan install is executed with the same
parameters, it will run very fast: packages are installed in the local cache, not inside the
$ git clone https://github.com/memsharded/example-hello.git $ conan install ./example-hello -s build_type=Debug --build=missing -if example-hello-build/debug $ conan install ./example-hello -s build_type=Release --build=missing -if example-hello-build/release $ cd example-hello-build/debug && cmake ../../example-hello -G "Visual Studio 14 Win64" && cd ../.. $ cd example-hello-build/release && cmake ../../example-hello -G "Visual Studio 14 Win64" && cd ../..
You can use the
-if to specify where to generate the output files or
create manually the directory and change to it before execute the
conan install command.
So the layout will be:
example-hello-build debug conaninfo.txt conanbuildinfo.txt conanbuildinfo.cmake CMakeCache.txt # and other cmake files release conaninfo.txt conanbuildinfo.txt conanbuildinfo.cmake CMakeCache.txt # and other cmake files example-hello conanfile.txt CMakeLists.txt # If using cmake, but can be Makefile, sln... main.cpp
Now you can switch between your build configurations in exactly the same way you do for CMake or other build systems, moving to the folder in which the build configuration lives, because the conan configuration files for that build configuration will also be there.
$ cd example-hello-build/debug && cmake --build . --config Debug && cd ../.. $ cd example-hello-build/release && cmake --build . --config Release && cd ../..
Note that the CMake
INCLUDE() of your project must be prefixed with the current cmake binary
directory, otherwise it will not find the necessary file: