[question] how to specify `requires`/`tool_requires` for same dependency.

• I’ve read the CONTRIBUTING guide.

How does one add a requirement for both build and runtime?

I would like to build autoconf so have the following:

    def requirements(self) -> None:
        self.requires(f"perl/5.34.1@{self._channel}")
        self.requires(f"m4/1.4.19@{self._channel}")

    def build_requirements(self) -> None:
        self.tool_requires(f"make/4.3@{self._channel}")
        self.tool_requires(f"m4/1.4.19@{self._channel}")
        self.tool_requires(f"perl/5.34.1@{self._channel}")

As perl/m4 is needed for both building and runtime of autoconf. However, doing conan info $PWD/package/autoconf results in the following:

Requires:
    perl/5.34.1@mychannel/testing
    m4/1.4.19@mychannel/testing
Build Requires:
    make/4.3@mychannel/testing

This means that the build fails beacause perl and the m4 binaries are not exposed on the PATH for the build.

How do I get both: expose the requirement to the build and use the requirement at runtime.

I’m using host/build contexts with 1.47 and trying to make my recipes as Conan v2 compatible as possible.

[mattyclarkson]

OK, found it and figured it out 🎉

In the test_package we have:

def build_requirements(self):
    self.tool_requires(self.tested_reference_str)

That was a misunderstanding when reading the docs

What that does is adds the top level package (autoconf) in the build context.

When the dependencies in autoconf are resolved, they all ge put in the build context. This means that when the dependencies are updated they overwrite each other due to the ID for the node being calculated with the reference name and the context.

I think the correct way to do this is:

def requirements(self):
    self.tool_requires(self.tested_reference_str)

That’ll put autoconf into the host context. I’m not 100% sure if that’s the correct thing because the example in here:

    def build_requirements(self):
        self.test_requires(self.tested_reference_str)

I assume that test_requires put the reference string in the host context.

I’ll have to look around at the best practices here for testing binaries within Conan.

@memsharded thanks for all the help, certainly learnt a lot here and it was totally on us.

It would be pretty cool if we could deny calling the tool_requires in build_requirements in the test package somehow (unless that is a valid use case…)

[memsharded]

I think I am a bit confused again 😅

In Conan 1.X the self.tool_requires() inside requirements() wouldn’t be valid.

It sounds like there still could be some failure mode that I am missing, do you think it would be possible to reproduce what you are commenting in the test in your PR in https://github.com/conan-io/conan/pull/11213?