[bug] Unable to map additional imported locations

[sykhro]

Describe the bug

OS: Any Conan version: 2.2.0

Using conan with a proprietary platform (thePlatform) that defines its own build types. For the purpose of this report, I will call it MyBuildType.

MyBuildType is akin to Debug and there is a necessity to setMAP_IMPORTED_CONFIG_MYBUILDTYPE to Debug for any non-conan imported targets. For this, I use set(CMAKE_MAP_IMPORTED_CONFIG_MYBUILDTYPE Debug).

However, with that variable set, every single conan target starts screaming:

CMake Error in path/to/some/CMakeLists.txt:
   IMPORTED_LOCATION not set for imported target
   "CONAN_LIB::flatbuffers_flatbuffers_libflatbuffers_flatbuffers_MYBUILDTYPE"
   configuration "MyBuildType".

Note that, in the Conan profile for the platform, build_type=MyBuildType

How to reproduce it

1. Unpack provided sample somewhere
2. Add MyBuildType to settings.yml
3. conan install . -s:h "build_type=MyBuildType" -d full_deploy --deployer-folder "$PWD/out" --output-folder "$PWD/out" --build=missing -g CMakeToolchain -g CMakeDeps
4. cmake -B build -G "Ninja Multi-Config" -DCMAKE_CONFIGURATION_TYPES="MyBuildType;Release" && cmake --build build --config MyBuildType
5. Observe that everything works
6. Uncomment line 6 in CMakeLists.txt, run cmake --build build --config MyBuildType

CMake Error in CMakeLists.txt:
  IMPORTED_LOCATION not set for imported target
  "CONAN_LIB::fmt_fmt_fmt_fmt_MYBUILDTYPE" configuration "MyBuildType".

reproducer.zip

[memsharded]

Hi @sykhro

Thanks for your report and specially for the reproducer.

I am having a look.

First quick feedback:

include(out/conan_toolchain.cmake)

Please do not include toolchains from CMakeLists.txt. The toolchain must be passed externally with cmake ... -DCMAKE_TOOLCHAIN_FILE=....conan_toolchain.cmake. The behavior and the result is not the same.

If I run the above steps in Windows, I get:

fmt/10.2.1: Running CMake.configure()
fmt/10.2.1: RUN: cmake -G "Visual Studio 17 2022" -DCMAKE_TOOLCHAIN_FILE="generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="C:/Users/memsharded/.conan2/p/b/fmtf6bf24ba447c7/p" -DFMT_DOC="OFF" -DFMT_TEST="OFF" -DFMT_INSTALL="ON" -DFMT_LIB_DIR="lib" -DFMT_OS="ON" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" "C:\Users\memsharded\.conan2\p\b\fmtf6bf24ba447c7\b\src"
-- CMake version: 3.25.3
-- Using Conan toolchain: C:/Users/memsharded/.conan2/p/b/fmtf6bf24ba447c7/b/build/generators/conan_toolchain.cmake
-- Conan toolchain: CMAKE_GENERATOR_TOOLSET=v143
-- Conan toolchain: C++ Standard 14 with extensions OFF
-- Conan toolchain: Setting BUILD_SHARED_LIBS = OFF
-- Selecting Windows SDK version 10.0.22621.0 to target Windows 10.0.19045.
-- The CXX compiler identification is MSVC 19.38.33135.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.38.33130/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Version: 10.2.1
-- Build type: Release
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/memsharded/.conan2/p/b/fmtf6bf24ba447c7/b/build

fmt/10.2.1: Running CMake.build()
fmt/10.2.1: RUN: cmake --build "C:\Users\memsharded\.conan2\p\b\fmtf6bf24ba447c7\b\build" --config MyBuildType
MSBuild version 17.9.8+b34f75857 for .NET Framework

C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppBuild.targets(452,5): error MSB8013: This project doesn't cont ain the Configuration and Platform combination of MyBuildType|x64. [C:\Users\memsharded\.conan2\p\b\fmtf6bf24ba447c7\b\build\ZERO_CHECK.vcxproj]

I am not sure why it works for you, maybe it is that in other OS, the build scripts of fmt are more permissive and will build even for an unknown build_type? Can you please share the logs of the building of fmt with the custom build-type?

[sykhro]

Please do not include toolchains from CMakeLists.txt. The toolchain must be passed externally with cmake ... -DCMAKE_TOOLCHAIN_FILE=....conan_toolchain.cmake. The behavior and the result is not the same.

Thanks, noted. However, in my actual usecase, I remove many blocks from the toolchain and only keep the search paths.

I am not sure why it works for you, maybe it is that in other OS, the build scripts of fmt are more permissive and will build even for an unknown build_type? Can you please share the logs of the building of fmt with the custom build-type?

Sorry, I forgot to mention, it needs Ninja Multi-Config (or a mess of custom Build.Props). I'm setting it in the profile for this toolchain. I have reproduced this:

• compiling for Linux on Linux
• compiling for Windows on Windows with clang-cl
• compiling for thePlatform on Windows

[sykhro]

... the build scripts of fmt are more permissive and will build even for an unknown build_type?

It may come as a surprise but so far the most random recipes from conan-center have built fine with this build_type and 0 changes required to the packages themselves. In my experience of porting to cursed platforms, building dependencies has never been this painless :)

[memsharded]

With

conan install . -s:h "build_type=MyBuildType" -d full_deploy --deployer-folder=out --output-folder=out --build=missing -g CMakeToolchain -g CMakeDeps -c tools.cmake.cmaketoolchain:generator="Ninja Multi-Config"

[vcvarsall.bat] Environment initialized for: 'x64'
ninja: error: loading 'build-MyBuildType.ninja': The system cannot find the file specified.

It may come as a surprise but so far the most random recipes from conan-center have built fine with this build_type and 0 changes required to the packages themselves. In my experience of porting to cursed platforms, building dependencies has never been this painless :)

Yes, a bit surprising :) Are you building for Windows too?

[sykhro]

With

conan install . -s:h "build_type=MyBuildType" -d full_deploy --deployer-folder=out --output-folder=out --build=missing -g CMakeToolchain -g CMakeDeps -c tools.cmake.cmaketoolchain:generator="Ninja Multi-Config"

[vcvarsall.bat] Environment initialized for: 'x64'
ninja: error: loading 'build-MyBuildType.ninja': The system cannot find the file specified.

It may come as a surprise but so far the most random recipes from conan-center have built fine with this build_type and 0 changes required to the packages themselves. In my experience of porting to cursed platforms, building dependencies has never been this painless :)

Yes, a bit surprising :) Are you building for Windows too?

I guess that the error is related to your profile being MSVC? For my Windows config, I have compiler=clang with the executable set to clang-cl.exe (I can't use MSVC unfortunately)

[memsharded]

Not really...

======== Input profiles ========
Profile host:
[settings]
arch=x86_64
build_type=MyBuildType
compiler=clang
compiler.version=16
os=Windows
[tool_requires]
*: ninja/[*]
[conf]
tools.build:compiler_executables={'cpp': 'clang++', 'c': 'clang', 'rc': 'clang'}
tools.cmake.cmaketoolchain:generator=Ninja Multi-Config


-------- Installing package fmt/10.2.1 (2 of 2) --------
fmt/10.2.1: Building from source
fmt/10.2.1: Package fmt/10.2.1:b55c038de9aa058b59f069fa5be24860b9ace96c
fmt/10.2.1: Copying sources to build folder
..
fmt/10.2.1: Generated aggregated env files: ['conanbuild.bat', 'conanrun.bat']
fmt/10.2.1: Calling build()
fmt/10.2.1: apply_conandata_patches(): No patches defined in conandata
fmt/10.2.1: Running CMake.configure()
fmt/10.2.1: RUN: cmake -G "Ninja Multi-Config" -DCMAKE_TOOLCHAIN_FILE="generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="C:/Users/memsharded/.conan2/p/b/fmtf7b8469784f80/p" -DFMT_DOC="OFF" -DFMT_TEST="OFF" -DFMT_INSTALL="ON" -DFMT_LIB_DIR="lib" -DFMT_OS="ON" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" "C:\Users\memsharded\.conan2\p\b\fmtf7b8469784f80\b\src"
-- CMake version: 3.25.3
-- Using Conan toolchain: C:/Users/memsharded/.conan2/p/b/fmtf7b8469784f80/b/build/generators/conan_toolchain.cmake
-- Conan toolchain: Setting BUILD_SHARED_LIBS = OFF
-- The CXX compiler identification is Clang 16.0.4 with GNU-like command-line
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/ws/LLVM/clang16/bin/clang++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Version: 10.2.1
-- Build type: Release
-- Performing Test HAS_NULLPTR_WARNING
-- Performing Test HAS_NULLPTR_WARNING - Success
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/memsharded/.conan2/p/b/fmtf7b8469784f80/b/build

fmt/10.2.1: Running CMake.build()
fmt/10.2.1: RUN: cmake --build "C:\Users\memsharded\.conan2\p\b\fmtf7b8469784f80\b\build" --config MyBuildType -- -j8
ninja: error: loading 'build-MyBuildType.ninja': The system cannot find the file specified.

Not sure what could I be missing here.

[sykhro]

It's most likely thatCMAKE_CONFIGURATION_TYPES is not set correctly and CMake has generated build-Release.ninja and build-Debug.ninja. thePlatform toolchain file sets it; I didn't need to set it on Linux though (on the conan invocation at least). I can't test on Windows for a couple days now, but I imagine you could work it around with a small toolchain file in the profile?

[memsharded]

Sure, passing a user_toolchain defining CMAKE_CONFIGURATION_TYPES works to build fmt

Now the command:

cmake -B build -G "Ninja Multi-Config" -DCMAKE_CONFIGURATION_TYPES="MyBuildType;Release" && cmake --build build --config MyBuildType

Fails, and this is expected, because it is not being passed the -DCMAKE_TOOLCHAIN_FILE=....conan_toolchain.cmake.

I am using cmake --preset conan-default instead and it worked. Then cmake --build --preset conan-mybuildtype did manage to build the .exe successfully.

Then, I tried to uncomment the line, and indeed it failed. It seems that Conan doesn't have enough information to handle this, but it can be passed. I made it work with profile:

[settings]
os=Windows
compiler=clang
compiler.version=16
build_type=MyBuildType
arch=x86_64
&:build_type=Debug

[conf]
tools.build:compiler_executables={"cpp": "clang++", "c": "clang", "rc": "clang"}
tools.cmake.cmaketoolchain:generator=Ninja Multi-Config
tools.cmake.cmaketoolchain:user_toolchain+={{os.path.join(profile_dir, "mytypes.cmake")}}

[tool_requires]
ninja/[*]

[buildenv]
PATH+=(path)C:/ws/LLVM/clang16/bin

Then:

rm -rf build && conan install . --build=missing -pr=profile && cmake --preset conan-default && cmake --build --preset conan-debug

[sykhro]

&:build_type=Debug

Oh, I had no idea this was possible. What's the meaning this syntax? Is it aliasing Debug to MyBuildType? Does it create any conflicts with the actual Debug build type wrt binary revision resolution?

[memsharded]

Oh, I had no idea this was possible. What's the meaning this syntax? Is it aliasing Debug to MyBuildType? Does it create any conflicts with the actual Debug build type wrt binary revision resolution?

The & is a pattern, all settings, options, confs, can be specified per-package like <pattern>:setting=value, like options with *:shared=True for making all dependencies shared libraries (when defined). The & is a pattern for the current "consumer" project. If you have a conanfile.py and define a name = "consumer", it will be equivalent to something like consumer/*:build_type=Debug, and it works for whatever name and current consumer is.

This allows to explicitly define the intention: "the current project is a Debug project, but I want the dependencies built with MyBuildType instead. Because Conan supports even more advanced cases than CMake, and I have seen conditional requirements depending on the build_type to depend on different versions, and this is possible with the explicit definition of the build_type for different packages.

[memsharded]

Any further question here? Maybe this issue can be closed now?

In any case we are already working in a new CMakeDeps in https://github.com/conan-io/conan/pull/16964 that will more explicitly model imported locations, feedback very welcome in that ticket.

[sykhro]

I'll try it again on Monday and will let you know (btw, I think you linked to this issue instead of a PR :)

[sykhro]

Scratch that actually, your suggestion worked fine. Will check that other ticket!

[memsharded]

Yes, sorry, the PR is https://github.com/conan-io/conan/pull/16964, I have fixed the above comment too