[question/feature request] support for default component

[tonka3000]

Hey,

First of all, I'm really happy to see the progress of components in conan, which is my most wished feature in conan.

I've read through #5090 , #6653 and most of the other issues and PR's to get a better picture about the vision behind components. I've maintain a big code base where we heavily using conan and have the usecase which you described in #5090 , #6653 , multiple exe, shared libs and so on, which we would like to reference/link from the conan consumer file/cmake code independently of the rest. And I'm totally aware that I'm not the only one who is waiting for that feature 😀.

A project where there are many static libs beside shared libs was never easy possible. Shared libs works fine, but exporting the static libs through conan target's (cmake) was not a viable solution (we always use user variables to pass all the requried info, which was really painful and feels like old cmake style).

I've read through most of your stuff, but for me some points are not 100% clear to me about the "final" version/vision of components

• Is it planned that components can have other components as dependency?
• Is every component available as cmake target, so it is easy linkable in cmake?
• Is there a possibility to define a default component?
  At the moment you collect the components (as far as I understand your concept) under an "umbrella target", like before 1.24, which is a viable solution to get in components nicely. So at the moment every sub-component defines the default component. I would like to define the default component, so that I can define which components are available in "umbrella target", so that I can add f.e. static libs easliy without fearing that the static lib component get linked through the "umbrella target". I like the default behaviour from conan, that I can just use CONAN_PKG::myproject in many cases, because it is so easy to use and so it would be super nice to have the best of both worlds 🙂.

I hope I explain my question well enough and sorry if you already answered the questions in other issues, i've tried my best to find the answers to my questions before writing this issue 🙋‍♂️🙂.

Greetings

Tonka

[danimtb]

Hi @tonka3000 and thanks a lot for the question.

As you have seen, we are introducing the feature in small iterations and the last part regarding the CMake implementation, it is still some releases away. However, we are thinking about it while we develop the general model in the cpp_info structure.

Currently (Conan 1.24), you are only able to define components at cpp_info level assuming declaration order and dependency of all components to all components. Components are still no visible to generators (no deps_cpp_info interface) and are all under the same CONAN_PKG::myporject CMake target.

In the next iteration, we would like to implement #6716 that will define the dependency among components under the same package and expose them later to generators in #6717

We would like to make a POC with the CMake generator #6718 with each component defining its own target as well as a general target that includes all of them (to keep the same behavior). Of course, you will be able to define your own components hierarchy and could create those "umbrella targets" the way you specify.

[tonka3000]

Thanks @danimtb for your answer.

I will close the issue to free up your open issues 😉