`cppinfo` improvements: components, exe, system deps...

[lasote]

Intro

The idea is to be able to specify different components (different libs, different exes) in the cpp_info object so it can help with:

• Modeling inter-dependencies in the same package, when a package is packaging more than 1 library, ex, OpenSSL (crypto, ssl) or Boost: Feature: model intra-package dependencies #2387
• Modeling also system dependencies: System library dependencies could be specified in the wrong order #2382
• Help with a future find_package generators to be able to give custom names to the target: Is there a way to override {name} and target name {name}::{name} for cmake_find_package #4430 (Package::module)
• Introduce the concept of "executables" in the cppinfo, so a consumer could receive information about the executables that the package exposes in variables, and the generators can also generate targets for the exes (in future refactor), like a target for protoc.

Proposition

• New fields to cpp_info:

  • self.cpp_info.name: It could be used by the generators to name the targets, config files etc. E.g: ZLIB. By default, the package name will be used.
  • self.cpp_info.exes: List of executable names (located in any self.cpp_info.bindirs). It could be used by the generators to export variables with the paths etc.
  • self.cpp_info.system_deps: List of system dependencies. (["dl", "pthread"])

• Subcomponents:

Enable self.cpp_info["component_id"], that is a very similar object to cpp_info with some exceptions:

• The component_id already gives the name of the component, can be used by the generators for example to name the component of the target: OpenSSL::Crypto for self.cpp_info["Crypto"].
• self.cpp_info["component_id"].name: The name for the subcomponent, by default the component_id will be the name.
• self.cpp_info["component_id"].lib: The library name
• self.cpp_info["component_id"].exe: The executable name (incompatible with specifying .lib)
• self.cpp_info["component_id"].deps: List with componen_ids.
• self.cpp_info["component_id"].system_deps: List with system library names.
• self.cpp_info["component_id"].libs: That won't exist
• self.cpp_info["component_id"].exes: That won't exist
• self.cpp_info["component_id"].name: The name doesn't exist, the "component_id" gives the name already.
• self.cpp_info["component_id"].rootpath: No sense

The subcomponents will also have available:

self.cpp_info["component_id"].includedirs 
self.cpp_info["component_id"].libdirs 
self.cpp_info["component_id"].resdirs 
self.cpp_info["component_id"].bindirs
self.cpp_info["component_id"].builddirs 
self.cpp_info["component_id"].defines
self.cpp_info["component_id"].cflags 
self.cpp_info["component_id"].cppflags
self.cpp_info["component_id"].cxxflags
self.cpp_info["component_id"].sharedlinkflags
self.cpp_info["component_id"].exelinkflags

If some of these elements are adjusted in the "general" object, the subcomponents will extend the values automatically, even if they do not use the append syntax:

self.cpp_info.include_dirs = ["include2"]
self.cpp_info["crypto"].include_dirs = ["include3"]

That will propagate ["include2", "include3"] as the include dirs for the crypto component.

---

Related to #4430

[ohanar]

For component deps, I think it is very important to be able to have granularity with specifying package dependencies component deps, and whether they are part of the public interface or not.

For instance, lets say I'm creating a package foo that depends upon qt and boost, and my package has a core component and gui component. I want to specify that the core component depends upon QtCore and as an implementation detail (in cmake speak, links privately against) boost::filesystem, and that the gui component additionally depends upon QtWidgets. When using only the core component of my library, you should only get the compilation flags for my library and QtCore (in particular no includedirs for boost), and link flags for my library, QtCore and boost::filesystem.

This sort of logic already exists in modern cmake targets, it would be nice to be able to get that information through the conan generator cmake targets as well. Right now to get this fine-tuned information, you have to create various config.cmake files to export this information, and then import it with find_packages and completely ignore conan's cmake generator.

[lasote]

Yes, the next needed features would be to improve the generators to allow, for example, to use find_package(XXX COMPONENT YYY). But first, we need the model.

#5091

[lasote]

This is an ongoing effort, moving to 1.17, I didn't expected to have it completed this iteration.

[danimtb]

Some conclusions for ongoing development after discussion:

• Make global usage (normal usage of cpp_info up-to-date) incompatible with components declaration
• Remove cpp_info.exes computation in components mode.
• Take system_deps order in cpp_info.libs computation.
• Consider usage of a cpp_info.components = True as opt-in.