[bug] CONAN_PKG::<PKG-NAME> silently stopped working in recent versions

[Bouloulou1138]

I am making the following calls to my CMake project:

include(${CMAKE_BINARY_DIR}/conanbuildinfo_multi.cmake)
conan_basic_setup(TARGETS)

Then I pass CONAN_PKG::<PKG-NAME> to CMake's TARGET_LINK_LIBRARIES command for linking my project with conan packages. One such package is CONAN_PKG::zlib.

All these used to work in version 1.11.2. But recently I updated conan to version 1.21.0. Then I did not notice any change when generating the project with CMake, the CONAN_PKG::<PKG-NAME> targets were still valid and CMake did not complain.

The issue was noticed when I tried to compile the generated Visual Studio project. Then I got compile errors, because VS could not find headers of the conan packages that I include, like zlib. Actually, the VS project did not have the include directories of these conan packages in its settings, so the compiler could not find them.

Since then I tried numerous things, like upgrading CMake, debugging Conan's CMake files but I could not find an issue. As I workaround I downgraded to Conan 1.11.2 and then things started working again(the include dirs reappeared normally in VS project settings).

Environment Details

• Operating System+version: Windows 10
• Compiler+version: Visual Studio 2017 15.8.1
• Conan version: 1.21.0
• Python version: Unknown
• CMake version: 3.15.2

[danimtb]

I think this might be a duplicate of #6269

[Bouloulou1138]

I am not sure. For example, in my case I do not get any error that CONAN_PKG::zlib does not exist. CMake does not complain and the project is generated without errors.

I also tried CONAN_PKG::zLib, CONAN_PKG::Zlib and CONAN_PKG::ZLIB targets and then CMake started complaining that these targets does not exist.

[uilianries]

@Bouloulou1138 which Conan package are you using in specific? Is it from CCI (Conan Center Index)? Did you try using the generator cmake_find_package ?

[Bouloulou1138]

One of the packages that I use is zlib/1.2.11@conan/stable. But the issue happens for every package that I try to link via CONAN_PKG::<PKG_NAME>

I've made some debugging by adding print calls in conanbuildinfo_multi.cmake and conanbuildinfo_debug.cmake, and it seems that everything is correct when properties are set to CONAN_PKG::<PKG_NAME> targets:

set_property(TARGET CONAN_PKG::zlib PROPERTY INTERFACE_LINK_LIBRARIES ...

Then in my cmake project, I hide CONAN_PKG::<PKG_NAME> targets behind a "stack" of variables:

SET( ZLIB_LIBS CONAN_PKG::zlib )
SET( LIBPNG_LIBS CONAN_PKG::libpng )
SET( EXTERNAL_LIBS ${LIBPNG_LIBS} ${ZLIB_LIBS } )

And I link the final variable to my cmake targets:

TARGET_LINK_LIBRARIES( myTarget PUBLIC ${EXTERNAL_LIBS} )

The above used to work in conan version 1.11.2. In newer versions, it seems that properties of CONAN_PKG::<PKG_NAME> are not inherited by my cmake targets.

[danimtb]

@Bouloulou1138 thanks for the info. I'd like to try to reproduce the issue to see what changed and if that is a bug in the current Conan version. Could you please provide me a small reproducible example? I think a conanfile.py/.txt and a small CMakeLists.txt (with the things mentioned above) will be enough

[Bouloulou1138]

I 've built an example stripped out of my project just to be sure that I will reproduce the issue. It is not very simple yet but I will simplify it further before posting it.

However, during the process of building this example, I discovered that the issue is present only for MinRelSize and RelWithDebInfo build types. The more common Debug and Release configurations work correctly(their settings in VS contain the include directories of conan packages).

It's a shame that I did not notice this earlier... Anyway, I hope it helps. In the meantime, I will try to simplify my example.

[Bouloulou1138]

And here is the example: CMakeTest.zip

I generated a Visual Studio 15 2017 x64 project using CMake 3.15.2
The Debug and Release configurations contain the include directories correctly, the MinSizeRel and RelWithDebInfo don't.

[danimtb]

Hi @Bouloulou1138 thanks a lot for the minimal example. Indeed I can confirm it works for release and debug but not for relwithdebinfo and minsizerel build types. I have to investigate it further but seems it is not related to #6269. I will investigate it further and see if I can propose a fix for it

[danimtb]

Ok, it seems that you have to run the CMake configure step when you add new configurations (cmake .. in my case). That made it work when I compiled the project and the header png.h was correctly found. Could you @Bouloulou1138 please verify this?

[Bouloulou1138]

Hello @danimtb , I did not understand exactly what you mean.
CMake by default sets the following configuration types in CMAKE_CONFIGURATION_TYPES variable:
Debug;Release;MinSizeRel;RelWithDebInfo

I do not modify them, I generate a VS project with those. Then in VS project I switch to the desired one, there is no need to modify CMake configuration for switching build types.

In any case, I tried modifying CMAKE_CONFIGURATION_TYPES by removing some of them and adding them back, but it didn't help.

[danimtb]

Here are the steps that are working in my case:

cd CMaketest
mkdir build && cd build
conan install .. -s build_type=Release
conan install .. -s build_type=Debug
conan install .. -s build_type=RelWithDebInfo
conan install .. -s build_type=MinSizeRel
cmake .. -G "Visual Studio 15 2017 Win64"

Then I open the generated solution CMakeTest.sln, and build the project selecting the different configurations in the drop-down topbar menu as usual.

Here you have the MinSizeRel one:

From my side this is working as expected using the example you provided me with.

[Bouloulou1138]

I tried and it works in my case too. However many of the conan packages that I use in my project are not available in MinSizeRel and RelWithDebInfo configurations, so conan needs to build them from source.

Is there a way to force conan to use Release packages for MinSizeRel and RelWithDebInfo configurations?

[danimtb]

Conan considers RelWithDebInfo and Release as two completely different configurations that have nothing to do with each other, maybe what you can do is using compatible packages so that your packages fallback to Release configuration if the RelWithDebInfo is not found.

Another approach (although more risky) would be forcing your dependencies with build_type=Release when compiling in RelWithDebInfo configuration using -s *:build_type=Release.

Anyway, we can discuss this in a different issue. Please close this one if the original problem was solved. Thanks!