[question] "control" cmake include dir variable about conan HOT 7 CLOSED

On my use case, the conan package has a folder inside "include" with some headers files which do not belong specifically to a component. Then, I guess, I shall refer it on components that depend on.

But you can create a component to refer to those headers, why not creating a "headers" component that define that includedirs? Then you have a way to refer to it. If you want to avoid having duplicated includedirs, then you can define a component .requires to this component with headers from other components using those common headers.

from conan.

Good, thanks for the feedback!

I am closing this question as responded then, don't hesitate to re-open or create new tickets for any further question.

from conan.

Hi @diogomatos3

Thanks for your question.

The way components works is that when components are defined, they fully invalidate/drop the global cpp_info.xxxdirs information. All information comes from components definition now, it is not possible to have components and at the same time have a global configuration, because having a global configuration means exactly that there are no components.

The the generic variable (conan-package_INCLUDE_DIR). becomes just the aggregation of the components. This variable represents the whole package information, not just a subset excluding the components.

from conan.

Hi @memsharded,

Thanks a lot for the quick reply and explanation. It fits completely what I have observed.
If you don't mind, one more question... how would be the proper/efficient way to have direct access to "include" folder of the package, in the consumers' cmakelists? Considering that components have different sets of includedirs.

from conan.

If you don't mind, one more question... how would be the proper/efficient way to have direct access to "include" folder of the package, in the consumers' cmakelists? Considering that components have different sets of includedirs.

That is the thing, there is no include folder of the package, if you define 2 components in one package and one has includedirs =["myinc1"] and the other has includedirs=["myinc2"], the consumer cannot obtain the "include" folder of the package, it doesn't exist. Maybe I am not fully understanding the issue.

Probably there is something else there. From the consumers it shouldn't be needed to get the includedirs and used them explicitly. The includedirs are already included in the generated targets, so just target_link_libraries(mytarget ... mydep::mydep) should be enough to automatically bring the includedirs of the dependencies and successfully find and use them.

from conan.

Ok, understood. My doubts are clarified.

You got the issue. I was just wondering if there was some way to "reach" include directly. But, like you said if there is components makes no sense to have interest on "include".

On my use case, the conan package has a folder inside "include" with some headers files which do not belong specifically to a component. Then, I guess, I shall refer it on components that depend on.

Thanks!

from conan.

I like this suggestion: "why not creating a "headers" component that define that includedirs"
It will be my approach. Thanks a lot for the guidance!

from conan.