This simple hello-world project uses Poco as a third party library. Poco is included in this project via Conan.

To install Conan, see the Conan documentation. It is recommended to use a virtual environment with python.

After you activated your virtual environment and installed Conan(see install packages), check if Conan is set up correctly by typing conan. Conan should have automatically set up a remote repository, the Conan center. If you type

conan remote list

you will get a list of all your remote repositories. For a new install this should be:

WARN: Remotes registry file missing, creating default one in [...]remotes.json
conan-center: https://conan.bintray.com [Verify SSL: True]

If you type

conan search poco

you will get the message

There are no packages matching the 'poco' pattern

which means that no Poco package is found in your local cache.

If you type

conan search poco --remote=conan-center

you will get an output similar to the following (depending on the remote Poco versions available):

Existing package recipes:

poco/1.8.1
poco/1.9.3
poco/1.9.4
poco/1.10.0
poco/1.10.1

There are two variants of how to use this repository. You can switch between them by enabling or disabling the CMake variable CONAN_CMAKE.

For the Conan install variant, see Conan install.

For the Conan cmake variant, see Conan CMake.

Conan is designed to work with one directory per configuration, something like

mkdir build_release && cd build_release
conan install ..
cmake .. -G ...
cmake --build .
cd ..
mkdir build_debug && cd build_debug
conan install .. -s build_type=Debug ...
cmake .. -G ... -DCMAKE_BUILD_TYPE="Debug"
cmake --build .

This works well with single-configuration generators (such as make and Ninja) where you have to define the CMAKE_BUILD_TYPE variable. This variable has to match the value of the -s build_type-option. Without the -s build_type-option a Release configuration is assumed (Conan default). The project's CMakeLists.txt sets the CMAKE_BUILD_TYPE variable to Release per default so everything works out of the box.

With multi-configuration generators (such as Visual Studio Generators or Xcode) it is uncommon to use multiple directories:

mkdir build && cd build
conan install ..
cmake .. -G ...
cmake --build . --config Release
cmake --build . --config Debug

Typically this allows e.g. a Visual Studio project to switch between different configurations inside an IDE. This does not work with Conan since the files automatically generated by conan install .. are not supposed to refer to different build types. The above written commands will lead to

error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug

So there are two options:

1. re-invoke the conan install .. command with conan install .. [-s build_type=Release] and conan install .. -s build_type=Debug each time a different configuration is needed
2. use one directory per configuration, similar to single-configuration projects

In both cases it is not possible to switch between different configurations inside an IDE.

With multi-configuration projects, like Visual Studio projects, it is uncommon to define the CMAKE_BUILD_TYPE variable. The typical way to configure and generate the project (using the conan install option inside the project's CMakeLists.txt - by enabling the CONAN_CMAKE variable and setting the CONAN_CMD variable to your Conan executable) would be something like :

mkdir build_release && cd build_release
cmake .. -G ... -DCONAN_CMAKE=TRUE -DCONAN_CMD=<path_to_your_conan_executable>
cmake --build . --config Release

That means that during the configure / generate step it is not clear which build type should be used. The function conan_cmake_run automatically assumes a multi-configuration generator if CMAKE_BUILD_TYPE is not set (which is automatically the case for multi-configuration generators). Since the cmake_multi-generator does not work with CMake's find_package (see Conan Issue #1177 on GitHub), this has to be prohibited. That's why the project's CMakeLists.txt sets the CMAKE_BUILD_TYPE variable to Release per default, even for multi-configuration generators.

Choosing a debug build type would be something like:

mkdir build_debug && cd build_debug
cmake .. -G ... -DCONAN_CMAKE=TRUE -DCONAN_CMD=<path_to_your_conan_executable>
cmake --build . --config Debug

This will lead to

error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug

The reason is that the CMAKE_BUILD_TYPE variable is set to Release per default and never changed when using a multi-configuration generator (see above: With multi-configuration projects, like Visual Studio projects, it is uncommon to define the CMAKE_BUILD_TYPE variable.).

To counter this behavior the CMAKE_BUILD_TYPE variable has to be explicitly set, also for multi-configuration generators, so the commands to be used would be something like:

mkdir build_debug && cd build_debug
cmake .. -G ... -DCONAN_CMAKE=TRUE -DCONAN_CMD=<path_to_your_conan_executable> -DCMAKE_BUILD_TYPE="Debug"
cmake --build . --config Debug

Everything applies to the configure / generate step using the CMake GUI as well. Waiting on Conan Issue #204 on GitHub for a better solution.