[bug] package_info() env variables not applied when pr:h matches pr:b

Environment Details (include every applicable attribute)

• Operating System+version: Ubuntu 18.04
• Compiler+version: gcc8
• Conan version: 1.33.1
• Python version: 3.6

Steps to reproduce (Include if Applicable)

– This may be a bug or me using conan the wrong way –

We had a CI pipeline that crosscompiled a bunch of libraries using the standard, single profile, approach. Recently we came across its limitations so we changed the workflow to use 2 profiles, the host one and the build one.

Since this is automated, we specify the build profile on a variable and then we list, for each package, the host profile to use. Something like:

buildProfile: x86_64
jobs:
  zlib:
    1.2.11:
      x86_64:
      arm:
      aarch64:
      mips:
  apriltag:
    1.2.11:
      x86_64:
      arm:
      aarch64:
      mips:

That file gets parsed so we always use x86_64 as the build profile, and the host profile is the result of iterating over the list under the version of a given package. When we build a package for x86_64, the host and build profile are the same, and I guess that is OK? But some packages fail to build, because the env variables defined in package_info are not visible to the test_package.

As an example, this happens for b2. This works as expected:

conan create recipes/b2/standard b2/4.2.0@eric/stable -pr x86_64

But this fails

conan create recipes/b2/standard b2/4.2.0@eric/stable -pr:h x86_64 -pr:b x86_64
...
...
b2/4.2.0@eric/stable (test package): Running test()
ERROR: b2/4.2.0@eric/stable (test package): Error in test() method, line 15
        os.environ['...'].replace("\\", "/")+"\" ;"
        KeyError: 'BOOST_BUILD_PATH'

But BOOST_BUILD_PATH is being defined in b2’s conanfile

    def package_info(self):
        self.cpp_info.bindirs = ["bin"]
        self.env_info.path = [os.path.join(
            self.package_folder, "bin")] + self.env_info.path
        self.env_info.BOOST_BUILD_PATH = os.path.join(
            self.package_folder, "bin", "b2_src", "src", "kernel")

Is this a bug or I’m not allowed to have matching build and host profiles? I know it doesn’t make much sense, but from the automation point of view is super easy for us to list the build profile once (since it is always the same) and then just change the host accordingly.

Thanks!

[ericriff]

Just for the sake of testing, I added this to the test_package conanfile

def build_requirements(self):
    self.build_requires("b2/{}@{}/{}".format(self.requires["b2"].ref.version, self.requires["b2"].ref.user, self.requires["b2"].ref.channel))

And it passes now, with one profile and with two 😃

[SSE4]

Thanks for clarifying that. Then about building a tool like b2 using two profiles. That is something that can’t be done using current conan behavior, right? I’m OK with closing this thread if that is the conclusion.

the b2 itself builds, and it can be successfully consumed via build_requires (in two profiles mode). the problem with test_package which fails. the entire test_package feature was designed long before we had any support for the cross-building, build_requires and two profiles. it was designed simply for testing regular library packages only, and can handle only that purpose.

however, in conan, there are many different relations between nodes in graphs:

• requirements (default and most wide-spread)
• private requirements
• build requirements
• python requirements
• consuming generators

test package only handles the first one (requirements). you probably should either completely skip test package for your case, or add build_requires node on your own (I am not sure it will work).

but my understanding is test_package is just wrong tool for build_requires - it’s like a using saw for nails instead of a hammer 😃