[bug] Using --profile:build makes private dependencies disappear from CONAN_PKG:: targets

[Paultergeist]

Environment Details (include every applicable attribute)

• Operating System+version: Ubuntu 20.04.2
• Compiler+version: N/A
• Conan version: 1.39.0
• Python version: 3.8.10

Steps to reproduce (Include if Applicable)

Sample project available here
In short:
Add private requirement to the recipe
Build without --profile:build - builds fine.
Build with --profile:build - CMake can't find corresponding CONAN_PKG::target.
Make requirement public - builds fine.

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

% conan create .
...
libTest/1.0: Created package revision d12aa99fb1d5a5830c83aa3f8aaf1757
% conan create . -pr default
...
libTest/1.0: Created package revision d12aa99fb1d5a5830c83aa3f8aaf1757
% conan create . -pr default -pr:b default
...
-- Configuring done
CMake Error at CMakeLists.txt:7 (add_library):
  Target "libTest" links to target "CONAN_PKG::gtest" but the target was not
  found.  Perhaps a find_package() call is missing for an IMPORTED target, or
  an ALIAS target is missing?
...
CMake Generate step failed.  Build files cannot be regenerated correctly.
libTest/1.0:
libTest/1.0: ERROR: Package '54899e12a3af6fe447947590ce807456934636ce' build failed
libTest/1.0: WARN: Build folder /home/paul/.conan/data/libTest/1.0/_/_/build/54899e12a3af6fe447947590ce807456934636ce
ERROR: libTest/1.0: Error in build() method, line 27
        cmake.configure(source_folder="src")
        ConanException: Error 1 while executing cd '/home/paul/.conan/data/libTest/1.0/_/_/build/54899e12a3af6fe447947590ce807456934636ce' && cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE="Release" -DCONAN_IN_LOCAL_CACHE="ON" -DCONAN_COMPILER="gcc" -DCONAN_COMPILER_VERSION="9" -DCONAN_CXX_FLAGS="-m64" -DCONAN_SHARED_LINKER_FLAGS="-m64" -DCONAN_C_FLAGS="-m64" -DCONAN_LIBCXX="libstdc++" -DBUILD_SHARED_LIBS="OFF" -DCMAKE_INSTALL_PREFIX="/home/paul/.conan/data/libTest/1.0/_/_/package/54899e12a3af6fe447947590ce807456934636ce" -DCMAKE_INSTALL_BINDIR="bin" -DCMAKE_INSTALL_SBINDIR="bin" -DCMAKE_INSTALL_LIBEXECDIR="bin" -DCMAKE_INSTALL_LIBDIR="lib" -DCMAKE_INSTALL_INCLUDEDIR="include" -DCMAKE_INSTALL_OLDINCLUDEDIR="include" -DCMAKE_INSTALL_DATAROOTDIR="share" -DCONAN_CMAKE_POSITION_INDEPENDENT_CODE="ON" -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY="ON" -DCONAN_EXPORTED="1" -Wno-dev '/home/paul/.conan/data/libTest/1.0/_/_/build/54899e12a3af6fe447947590ce807456934636ce/src'
% perl -npe "s#private=True#private=False#" -i conanfile.py
% git diff
diff --git a/conanfile.py b/conanfile.py
index c7feff5..7e3b4ae 100644
--- a/conanfile.py
+++ b/conanfile.py
@@ -16,7 +16,7 @@ class LibTestConan(ConanFile):
     exports_sources = "src/*"

     def requirements(self):
-        self.requires("gtest/1.10.0", private=True)
+        self.requires("gtest/1.10.0", private=False)

     def config_options(self):
         if self.settings.os == "Windows":
% conan create . -pr default -pr:b default
...
libTest/1.0: Created package revision a075cba8e91cc194d7ae6ad6effe3882

[SpaceIm]

Not only CONAN_PKG targets, it's also broken in cmake_find_package, cmake_find_package_multi & pkg_config generators.
They don't generate files for (direct) private requirements if dual profiles is used.

[memsharded]

This was recently fixed in new CMakeDeps and MSBuildDeps generators in #9517

[drmacdon]

Related to open ticket #8780

[Paultergeist]

Still reproducible with Conan 1.40.3.

It's even more annoying now with new core:default_build_profile in global.conf, need to comment the line every time I need to build such package, and then restore it back.

[memsharded]

@Paultergeist is it reproducible with the CMakeDeps and MSBuildDeps? It was fixed in #9517, and we added tests there to validate it. The legacy generators like cmake can't fix this now, we have had a look and it would be too risky, very high likelihood of breaking.

[Paultergeist]

@memsharded No, I was trying with cmake generator. I thought that it would be fixed eventually for it too.

I never used CMakeDeps generator, I'll try it a bit later and report.

[drmacdon]

I like CMakeDeps. With conan 1.41.0, I did notice if I set a requirement to be private=True that my imports() copy fail to occur for that dependency.

[drmacdon]

I also don't get any package configs generated for build_requirements() dependencies when I use:

conan install .. --build missing --profile:build default --profile:host default

build I do when I use:

conan install .. --build missing

Which both logically should be equivalent.

[drmacdon]

Using CMakeDeps in generate() and adding explicit entries to build_context_activated does provide the package configs for build_requirements.

private=True is still broken on package imports, and using private=False ends up generating too many package configs for my shared library built from statics.

Is there a way in package_info() to explicitly control which dependencies I want to expose?

[jblort]

I just encountered the same issue, and I'm a bit unsure how to handle that. Basically, all my private dependencies (and their dependencies) that worked fine with the cmake generator, now do not work anymore as Conan uses them as build_requirements instead. As in, when e.g. doing a conan install -pr:h android-armv8 -pr:b default .., I get a lot of logs like this:

Applying build-requirement: cairo/1.17.4

for actual requirements.

I'm not sure what should be done, as my recipe use the standard cmake generator and a CMakeLists which relies on the conan_basic_setup function and CONAN_LIBS variable, and, apologies if I missed it, but I'm not sure where I can find a good example of what should be now the proper way of integrating Conan with CMake.

[Paultergeist]

@memsharded Looks like it's not just cmake generator. deps_cpp_info is missing information about private dependency when --profile:build is used.
I've added this line at the beginning of build() method:

self.output.info(f"{self.deps_cpp_info['gtest'].rootpath}")

It builds fine with conan create . -pr default and prints path to gtest package:

libTest/1.0: Calling build()
libTest/1.0: /home/paul/.conan/data/gtest/1.10.0/_/_/package/71c983c52942eb4756e4bd60e4cbec9fd7557e5d

But if I build with conan create . -pr default -pr:b default it fails with this error:

libTest/1.0: Calling build()
libTest/1.0:
libTest/1.0: ERROR: Package '54899e12a3af6fe447947590ce807456934636ce' build failed
libTest/1.0: WARN: Build folder /home/paul/.conan/data/libTest/1.0/_/_/build/54899e12a3af6fe447947590ce807456934636ce
ERROR: libTest/1.0: Error in build() method, line 26
        self.output.info(f"{self.deps_cpp_info['gtest'].rootpath}")
        KeyError: 'gtest'

PS:

 % conan --version
Conan version 1.47.0

[Paultergeist]

Reproducible in 1.48.0.

[memsharded]

Yes, deps_cpp_info is also deprecated, and the new generators and build system integrations no longer use deps_cpp_info nor deps_env_info, but they use the new self.dependencies access: https://docs.conan.io/en/latest/reference/conanfile/dependencies.html

When using the 2 profiles, deps_cpp_info will no longer contain information from the build context.

[Paultergeist]

@memsharded I don't see the package in self.dependencies if it's a private requirement.

ERROR: conanfile.py (name/2.0.local): Error in build() method, line 45
        cmake.definitions["sdk_root"] = self.dependencies["package_name"].package_folder
        AttributeError: 'NoneType' object has no attribute 'dependencies'

Conan 1.59.0

EDIT: Interesting, conan create works, but mkdir build && cd build && conan install .. && conan build .. leads to this error.

[memsharded]

Hi @Paultergeist

I don't think this is because being private, but in Conan 1.X conan build is not "graph complete". It doesn't compute the dependency graph, just recovers some partial information about deps_cpp_info serialized in the conanbuildinfo.txt and other files. Conan 2.0 conan build command is "graph complete", will compute the full dependency graph and will have self.dependencies correctly defined.

In an case the self.dependencies should be typically used in the generate() method, to generate the necessary files that will be needed later for building in the build() method. All the modern integrations CMakeDeps, CMakeToolchain, MSBuildDeps, etc, only access self.dependencies from the generate() call, and the calls inside build() are just very thin wrappers around the command line syntax for calling the tool.