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

[datalogics-kam]

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.

[Paultergeist]

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.

[memsharded]

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!

[memsharded]

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!

[acronce]

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.

[Paultergeist]

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.

[memsharded]

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.

[acronce]

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.

[memsharded]

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

[SSE4]

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

[memsharded]

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

[SSE4]

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.