[bug] requires of a dependency of a dependency in build context not visible about conan HOT 3 OPEN

Hi @maximilianmuehlbauer

Thanks for your report.

To summarize the graph would be:

pkga_consumer -(requires)-> pkga(shared) --------(requires)--------->libb(shared) -(requires)-> libb_dep(shared)
                                    \--(build-require) ->pkgb(shared)-->/

I'd like to start with a recommendation: build=True, visible=True will be really discouraged in most cases. I have already had some experience trying it, and I would advice against this.

If the intention is that the pkga_consumer needs some tool-requires for itself, because it needs such tool requires to build itself, then that means that pkgb (shared-library) should be a direct dependency for pkga_consumer and it shouldn't be inherited from pkga

It would be also good to understand how shared libraries can be used as "tool-requires" (build=True), as this puts such libraries in the "build" context, so the binaries might actually be incompatible (cross-compilation) or inconsistent/incorrect (building for debug will still bring Release for the build context by default).

Thanks very much for your reproducible code, I will use it to make a test, and understand what could be happening.

from conan.

Thanks for the quick reply!

I'd like to start with a recommendation: build=True, visible=True will be really discouraged in most cases. I have already had some experience trying it, and I would advice against this.

Yes, Matlab is a very special case... one might have a model that depends on a Simulink library (like a C++ header-only lib), that depends on a library, ... and at some point there's an sfunction. For building the final model, all of that is needed in the build environment which is where we run Matlab to generate the C++ code.

If the intention is that the pkga_consumer needs some tool-requires for itself, because it needs such tool requires to build itself, then that means that pkgb (shared-library) should be a direct dependency for pkga_consumer and it shouldn't be inherited from pkga

Yes, essentially that is what we want; however making an explicit tool requirement from pkga_consumer to the sfunction is hard as the name, version etc. of that sfunction would need to stay in sync with a possibly long dependency tree in between. We would like to give Matlab developers the possibility to depend on a library which might come with such sfunction in some place without explicitly having to specify that sfunction.

It would be also good to understand how shared libraries can be used as "tool-requires" (build=True), as this puts such libraries in the "build" context, so the binaries might actually be incompatible (cross-compilation) or inconsistent/incorrect (building for debug will still bring Release for the build context by default).

Yes, those libraries will be incompatible (and cross-compiling actually works with pkga as root). The sfunction in pkgb might need libpkgb to generate code (but it's a normal requires of pkgb -> to my understanding, it should land in build context as soon as pkg is put in build context in that case) while the generated code links against libpkgb for possibly a different architecture.

from conan.

I have been having a look and so far it seems the build=True trait has higher priority than the visible=True one, so build-requires are still not being fully propagated. I will keep investigating tomorrow if it is possible to do this propagation without risks of breaking.

from conan.