[question] How to specify a package that is both a build and normal requirement?

[planetmarshall]

What is your question?

Hi - I have a problem I'm trying to solve in this clang recipe

The recipe works for an entirely static graph, but fails at build time when depending on shared libraries.

The problem is that the package depends on llvm-core, both to run executables from that package at build time, and to provide upstream libraries when the recipe is actually consumed. The executables depend on shared libraries provided by conan, and are failing at build time with error while loading shared libraries errors.

I tried

self.requires(f"llvm-core/{self.version}", transitive_headers=True,  build=True, visible=True)

but then I get an error

KeyError: "'llvm-core' not found in the dependency set"

when I try to call

llvm = self.dependencies["llvm-core"]

At generation time, which is necessary to set some CMake variables based on the configuration of llvm-core.

How should I approach this?

Many thanks for any help.

Have you read the CONTRIBUTING guide?

• [x] I've read the CONTRIBUTING guide

[planetmarshall]

Looking at the generated conanbuildenv-release-x86_64.sh folder - it contains the appropriate environment variables for the llvm-core package to use at build time, but does not contain LD_LIBRARY_PATH vars for the transitive dependencies.

...
export PATH="/home/andrew/.conan2/p/cmakec09d2d9fb89a5/p/bin:/home/andrew/.conan2/p/b/llvm-9145824fb6864/p/bin:$PATH"
export LD_LIBRARY_PATH="/home/andrew/.conan2/p/b/llvm-9145824fb6864/p/lib:$LD_LIBRARY_PATH"
export DYLD_LIBRARY_PATH="/home/andrew/.conan2/p/b/llvm-9145824fb6864/p/lib:$DYLD_LIBRARY_PATH"

[memsharded]

Hi @planetmarshall

Thanks for your question.

have you reviewed the example in https://docs.conan.io/2/examples/graph/tool_requires/using_protobuf.html?

In short, you need to self.requires("dep/version") and self.tool_requires("dep/version") (optionally, you can use the <host_version> placeholder to simplify aligning the versions.

[planetmarshall]

Hi @planetmarshall

Thanks for your question.

have you reviewed the example in https://docs.conan.io/2/examples/graph/tool_requires/using_protobuf.html?

Thanks - I'll take a look at that.

[lo1ol]

It's looks like not a complete solution. Host part of protobuf generates headers. Headers could be used with any profile after that.

What about tools, that generate host specific artifacts? For example, toolchains. Compilers could be run only on specific host and generates files for another specific host. It couldn't be separated: build and host profile should be used during search of single package

I already faced with it this problem. My team have crosstool-ng toolchains. This toolchains builds linux x86_64 programs. This toolchain could be used under macOS and linux machines. (it's two different versions of it)

I think it could be cool to store this toolchains in conan packages and download specific version depending in your host.

Of course on practice linux programs built under linux. And on ci I need only linux version's of this toolchains. Developers could build this toolchains by their own under macOS and use it. But the scenario is still looks real

[memsharded]

What about tools, that generate host specific artifacts? For example, toolchains. Compilers could be run only on specific host and generates files for another specific host. It couldn't be separated: build and host profile should be used during search of single package

This use case is explained here: https://docs.conan.io/2/examples/cross_build/toolchain_packages.html

It uses the settings_target in different points of the recipe, including the package_id(), to give the binary that targets a specific host as target its own different binary package_id and identity.

[lo1ol]

thank you! it's really works)

[memsharded]

Thanks for the feedback @lo1ol

Did you manage to try that @planetmarshall ? any further question here?