[feature] Add support for self.conf_info_target (or propagate self.conf_info only to host context)

[DoDoENT]

What is your suggestion?

I'm writing a tool-requires package that will be part of the profile. The idea of the package is to enforce some compile flags to all packages, regardless if they are internal, or from conan-center.

The rough idea is something like already discussed in this question

For the sake of simplicity, let's say that the recipe looks like this:

from conan import ConanFile

class Foundation(ConanFile):
    name = 'foundation'
    version = '0.1.0'
    settings = 'os', 'arch', 'build_type', 'compiler'

    def package_id(self):
        self.info.clear()

    def package_info(self):
        if self.settings_target.build_type == 'Release':
            flags = ['-flto=thin']
        elif self.settings_target.build_type == 'Debug'
            flags = ['-fsanitize=address']

        self.conf_info.append('tools.build:cflags', flags)  # problematic line, see explanation below

Now, let's say we have a simple default profile that looks like this:

[settings]
arch=armv8
build_type=Release
compiler=clang
compiler.libcxx=libc++
compiler.version=16.0.5
os=Linux
[tool_requires]
*: mb_foundation/0.1.0@microblink/stable

Now, let's have a protobuf-like package, that contains both binary and library. Let's call it my_protobuf. Let's also say that my_protobuf depends on libbacktrace/cci.20210118 from the conan center.

Now, we install our package in debug mode with following command:

conan install . -s build_type=Debug --build missing

The installation resolves to the following profiles:

Profile host:
[settings]
arch=armv8
build_type=Debug
compiler=clang
compiler.libcxx=libc++
compiler.version=16.0.5
os=Linux
[tool_requires]
*: mb_foundation/0.1.0@microblink/stable

Profile build:
[settings]
arch=armv8
build_type=Release
compiler=clang
compiler.libcxx=libc++
compiler.version=16.0.5
os=Linux
[tool_requires]
*: mb_foundation/0.1.0@microblink/stable

Conan correctly concludes that both Release and Debug version of my_protobuf and libbacktrace needs to be built, however, the problem is that the Release version of those packages ends up getting built with -fsanitize=address, just like the Debug version. This then causes linker issues later and especially if such a package gets uploaded to the Artifactory and used later.

The problem is in the line marked above: self.conf_info.append('tools.build:cflags', cflags) - this gets propagated to both host and build contexts. For propagating flags just to the build context, I can use self.cpp_info.cflags = cflags, but I have no way of propagating the flags exclusively to the host context.

Ideally, I would like to be able write a recipe like this:

from conan import ConanFile

class Foundation(ConanFile):
    name = 'foundation'
    version = '0.1.0'
    settings = 'os', 'arch', 'build_type', 'compiler'

    def package_id(self):
        self.info.clear()

    def package_info(self):
        if self.settings_target.build_type == 'Release':
            host_flags = ['-flto=thin']
        elif self.settings_target.build_type == 'Debug'
            host_flags = ['-fsanitize=address']

        self.conf_info.append('tools.build:cflags', host_flags)

        if self.settings_build.build_type == 'Release':
            build_flags = ['-flto=thin']
        elif self.settings_build.build_type == 'Debug'
            build_flags = ['-fsanitize=address']

        self.cpp_info.cflags = build_flags

Is such a thing maybe possible even today with conan 2.0.9, but undocumented (just like settings_target and settings_build exist, but are undocumented)?

In general, I think that toolchain packages should have the ability to propagate their flags exclusively to the host context.

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[DoDoENT]

OK, it appears that self.cpp_info is not being propagated to the build context - I can't see these flags anywhere, but conf_info flags I see in both host and build contexts.

[memsharded]

Just to follow up, I haven't abandoned this, I am working on #14441, that includes a fix (not a feature, this would be more like a bug in the computation of settings_target). Hopefully this can be for next 2.0.10

[memsharded]

Sorry, above had wrong link, I have updated it The right PR is #14441, if you would like to test it running from source for your project, that would be great feedback.

[memsharded]

#14441 is merged for next 2.0.10, if you want to give it a try from the release/2.0 branch, that would be great feedback.

[DoDoENT]

Sorry for the late answer, I was on vacation for the past 3 weeks.

I can confirm that with 2.0.10-dev from the release/2.0 branch libbacktrace is correctly built for both debug and release types when using special build-type-dependent flags, as described above.

Also, in your PR I see the use of undocumented self.context. This could be useful for situations like these, i.e. to define different flags for build vs host contexts. Is that something that you plan to keep as private API or will it be documented?

Also, when is the planned release date for 2.0.10?

[memsharded]

Thanks for the feedback!

We are closing 2.0.10 now, hopefully tomorrow is out.

Yes, self.context will most likely be documented.