Conan: [bug] Framework library X not found in paths: <blank>

Created on 25 Jan 2020  路  11Comments  路  Source: conan-io/conan

Environment Details (include every applicable attribute)

  • Operating System+version: macOS 10.14.6
  • Compiler+version: Xcode 10.3
  • Conan version: 1.21.1
  • Python version: 3.6.5

Steps to reproduce (Include if Applicable)

  • Consume a package that declares self.cpp_info.frameworkdirs and self.cpp_info.frameworks

Logs (Executed commands with output) (Include/Attach if Applicable)

CMake Error at /Users/kam/src/dl/X/build/conanbuildinfo.cmake:26 (message):
  Framework library X not found in paths:
Call Stack (most recent call first):
  /Users/kam/src/dl/X/build/conanbuildinfo.cmake:180 (conan_find_apple_frameworks)
  CMakeLists.txt:24 (include)

What it looks like is that the generated conanbuildinfo.cmake is calling conan_find_apple_frameworks to find the frameworks for the consumed package, let's call it A, and it doesn't find framework X.

The CONAN_FRAMEWORK_DIRS variable is set _way_ later in the file, on line 568. Thus, there are no dirs to search, and then you get an error. Once the CONAN_FRAMEWORK_DIRS variable is set, it _does_ contain framework X.

The product is proprietary, so I can't give you full unredacted sources. I can answer questions, and I wanted to get this entered in case you had seen this.

Most helpful comment

Hi @datalogics-kam

This has been fixed in #6533, will be released in Conan 1.23 (not a regression, it really never worked).
If you could run from the develop branch to test it works in your case too, that would be great. Many thanks!

All 11 comments

It's easy to reproduce with a very simple recipe that generates a framework. I've created one here.

Just build the framework using conan create . test/test and then use it in the app with
conanfile.txt:

[requires]
apple_framework/1.0.0@test/test

and CMakeLists.txt from conan docs:

cmake_minimum_required(VERSION 3.16)
project(app)

include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup()

add_executable(timer timer.cpp)
target_link_libraries(timer ${CONAN_LIBS})

You'll get the error that @datalogics-kam described.

Converting this info to a test in https://github.com/conan-io/conan/pull/6499/files.

Thanks very much for providing the code and all the feedback!

Hi @datalogics-kam

This has been fixed in #6533, will be released in Conan 1.23 (not a regression, it really never worked).
If you could run from the develop branch to test it works in your case too, that would be great. Many thanks!

I'm seeing the same problem with Xcode 11.4.1, even after updating to Conan 1.25.1.

I've done some printf debugging and it appears that CMAKE_BUILD_TYPE is undefined at the time that conan_find_apple_frameworks is called for a multi-config build. This results in the CONAN_FRAMEWORK_DIRS${SUFFIX} variable not being set to the defined per-config framework dirs (like CONAN_FRAMEWORK_DIRS_QT_RELEASE, for example), so conan_find_apple_frameworks has no directories to search.

I hope this isn't just me being stupid. In case it's relevant, here's how I'm invoking conan_cmake_run:

# Set the configuration types to pass to the conan install based on whether this is
# a single or multi-config platform.
if (SINGLE_CONFIG_BUILD)
    set(PLATFORM_CONFIG_TYPES "${CMAKE_BUILD_TYPE}")
else()
    set(PLATFORM_CONFIG_TYPES "Release;Debug")
endif()

# Perform the conan installation of required packages, copying them from our remote if
# possible, and building them locally they are missing and not on the remote.
message(STATUS "Launching conan install from within cmake...")
conan_cmake_run(REQUIRES ${CONAN_REQUIRES}
                BASIC_SETUP CMAKE_TARGETS NO_OUTPUT_DIRS
                CONFIGURATION_TYPES ${PLATFORM_CONFIG_TYPES}
                BUILD missing)

Note that SINGLE_CONFIG_BUILD will not be defined in this case because it's a multi-config build.

Thanks in advance for any suggestions.

This now works on macOS, but not on iOS and tvOS.
I've updated the sample project.
I've also added test scripts for easier testing - just run one of them to reproduce on corresponding platform.

Reopening issue, assigning for investigation in next 1.27.

A couple of suggestions:

  • It is typically better to create new issues than commenting on closed ones, if you think that there is still buggy behavior, better file a new issue.
  • It is better to reproduce things first without using the conan.cmake functionality (conan_cmake_run()) to isolate better the issue, and rule out possible conan.cmake issues.

Thanks for the feedback and the code to reproduce, we will have a look at it soon.

Sorry that I didn't create a new issue. But this seemed like the same problem.

After digging more I realize it's specifically related to conan_cmake_run and multi-config builds. So while it might be a different cause, the effect is the same.

You've probably seen the activity on my pull request. It's still a bit unclear if the fix to conan_find_apple_frameworks is correct, or if setting CMAKE_BUILD_TYPE prior to loading the conanbuildinfo files (like conanbuildinfo_release.cmake) is better. I'm tending towards the latter because it seems like a more general solution.

Hi!

This should have been fixed by https://github.com/conan-io/conan/pull/7341, which has already been merged to develop, and will be available in next Conan 1.28.

Could someone please run from develop branch to verify it? (Otherwise the package in PyPI-test will be available later today, when CI passes)

cc / @SSE4

there seems to be one more issue, different from #7341. example works for macOS, but not for iOS/tvOS.

I see. The example was coded in a test in https://github.com/conan-io/conan/pull/6499/files. Maybe we can extend that test to make it fail under iOS and tvOS? Could you please try that @SSE4 ?

Seems we are a bit late for fixing this in 1.28, moving it to next 1.29

yeah, I am going to try that. I think it might be the difference on how find_library works when cross-compiling, e.g. we might need to set parameters like CMAKE_FIND_ROOT_PATH_BOTH.

Was this page helpful?
0 / 5 - 0 ratings