[bug] & settings specifier removes * specified settings for conan create

[jarro2783]

Describe the bug

Conan version: 1.64.1

When I build a package with conan create, if my profile has a setting specified with &:, then it erases other settings that are specified with pattern matching syntax. Full details of how to reproduce are given below.

How to reproduce it

This is a smaller reproduction of our real problem, so note that if this example looks a bit weird, it is because this exhibits the same symptoms but without having to set the custom settings that I am using.

For the following profile:

[settings]
arch=x86_64
*@test/*:build_type=Release

os=Linux
compiler=gcc
&:compiler.version=12
compiler.libcxx = libstdc++

If I build some package directly from the conan center repository, example zlib, like this:

conan create . zlib/1.2.13@test/test -pr:h ./release

then the build_type setting is not applied. For this example the build fails with this error:

zlib/1.2.13@test/test: WARN: Build folder /sandbox/jarryd.beck/.conan-data/zlib/1.2.13/test/test/build/eb0d15964bd8716b19c1f7574dbe17441af10129/build/None
ERROR: zlib/1.2.13@test/test: Error in build() method, line 86
    cmake.build()
    ConanException: build_type setting should be defined.

If I remove the &: from compiler.version then build_type is set and the package builds correctly.

[memsharded]

Hi @jarro2783

Thanks for your report.

This was a known behavior in Conan 1.X, that couldn't be fixed back then, it had some risks.

It has been already fixed in Conan 2 (released almost 1 year and half ago), I have just tested above and it works (it will fail in the test_package stage, but that is totally expected because the test_package stage isn't a @test/test package, and as such doesn't have the build_type defined and it is expected to fail).

I have also added a test that proves it works in Conan 2, I will add it as a PR to close this ticket, as I am afraid this cannot be changed in Conan 1.

As a side recommendation, the channel is no longer recommended to denote maturity stages. For creating packages from conan-center-index forks, it is not recommended to use any user/channel at all, please check https://docs.conan.io/2/devops/using_conancenter.html and https://docs.conan.io/2/devops/conancenter/hosting_binaries.html. Note that Conan 2 also added new features to maintain forks of conan-center-index repo: https://docs.conan.io/2/devops/devops_local_recipes_index.html

Thanks very much for the feedback!

[memsharded]

Regarding the usage and possible solutions in Conan 1, the approach would be to specify the different settings for the same pattern (as the issue is that Conan 1 is grouping settings per pattern). So something like this:

[settings]
arch=x86_64
os=Windows
compiler=msvc
&:compiler.version=193
&:build_type=Release
compiler.cppstd=14
compiler.runtime=dynamic
*@test/*:build_type=Release

would make it work.

To avoid repetitions if there are a lot of them, then maybe a profile.jinja jinja templated profile could help.

[jarro2783]

Thanks for your reply and the workaround. I have also found that conan export and then conan install --build=package works. I am not building conan center packages with a channel, it just happened to be the easiest way to demo the problem.

In our case we are trying to build our internal packages with an address sanitizer setting and a microarch setting, but at the same time we don't want them applied to conancenter packages, so it's a bit fiddly the way we had to specify the settings in our profiles, but hopefully we can come up with a way to make it work.

[memsharded]

In our case we are trying to build our internal packages with an address sanitizer setting and a microarch setting, but at the same time we don't want them applied to conancenter packages, so it's a bit fiddly the way we had to specify the settings in our profiles, but hopefully we can come up with a way to make it work.

Thanks for the feedback. Yes, I think the best approach would be to make sure to define the full configuration for the *@myuser and the & patterns. Maybe using include(profile) or profile composition with multiple -pr=profile1 -pr=profile2 helps maintaining things clearer.

Then, when upgrading to Conan 2, you will be able to simplify that.

[memsharded]

Merging https://github.com/conan-io/conan/pull/16608 has automatically closed this issue as solved in Conan 2.

Please don't hesitate to reopen or create new tickets for any further question you might have. Thanks!