Conan: Package settings are buggy if modified in the conan recipe

[Sebiee]

• [x] I've read the CONTRIBUTING guide.
• [x] I've specified the Conan version, operating system version and any tool that can be relevant.
• [x] I've explained the steps to reproduce the error or the motivation/use case of the question/suggestion.

System info

Conan version: 1.3.0
Operating System: Debian 9 (stretch)

Bug explanation

If you modify the _compiler.libcxx_ setting to _libstdc++11_ in the _configure_ method of a package, that package will be specified as having _compiler.libcxx=libstdc++11_, but if you use the setting _compiler.libcxx=libstdc++_ in the making of another package that requires the first package, then conan says this is ok, it doesn't show the warn that a package with the desired options does not exists.
That warn appears and the install is stopped if the scenario is the same, but only the first package doesn't modify the settings in the configure method, but specify it through cmd line.

Shortly, you end up having a package with some settings that you can use to build other package with different settings.

Steps to reproduce

I set up the scenario at this repo.
If you have in the default profile _compiler.libcxx=libstdc++_, from the root dir of the project, do:

mkdir build
cd build
conan install ..
conan build ..
conan export-pkg .. aa/aa
conan test ../test_package string_wrapper/1.0.0@aa/aa

[memsharded]

Hi @Sebiee

Thanks for your detailed report. I think there is some misunderstanding here regarding what the settings are, and how to use them.
Settings are "inputs" to the system. They declare the platform configuration that you are going to use, and the installed dependencies should be the correct ones for that configuration.

It doesn't make sense that a recipe changes a setting value in its configure() method. What does it means to do self.settings.os = "Windows" if you are running in Linux? The same applies for the libcxx, it shouldn't be understood as an interface to the build system that you can change. When you say:

$ conan install . -s compiler=gcc -s compiler.version=6.3 -s compiler.libcxx=libstdc++11

It means that you are going to use that compiler and link with the libstdc++11 library. Recipes shouldnt change that. If you want to define your configuration of settings, the place to do it is in profile files.

The reason you are seeing the same package ID, is because the package ID is actually computed with a copy of the settings, stored in the self.info object.

Please tell me if this makes sense, and if you have further question. Thanks!

[Sebiee]

The reason you are seeing the same package ID, is because the package ID is actually computed with a copy of the settings, stored in the self.info object.

Then, what does it mean if i "remove" some settings in the configure method, as you specified in other comments on some issues. How does this gets in the package ID?

I understand now the usability of the settings and that makes sense.
Even so, this thing that i described made me loose some time, because that was what we were doing in our recipes, namely, modifying the settings and this raised a stack smashing error when changed the compiler.
Could it be taken into account making the settings immutable or at least be specified a warning somewhere if settings modification is detected? Like, comparing the copy of the settings you mentioned with self.settings.

[memsharded]

Then, what does it mean if i "remove" some settings in the configure method, as you specified in other comments on some issues. How does this gets in the package ID?

Sorry, you are right. It was a bad explanation. The reason of obtaining the same ID is that the configure() is overriding the command line specified libcxx, so the libstdc++11 binary is the one always used. If you remove some settings in the configure(), they should also dissapear from package ID.

The truth is that we already considered making them read-only, but it was not that obvious, so we thought better not add extra complexity (and run time) to the codebase. Also, it happens that the default settings specified by conan doesn't make sense to be modified in recipes, but many users are adding custom settings to settings.yml, and they might be writing their own logic in the recipes regarding those settings, so it is much preferred not to block them with such mode. In case of doubt we prefer to choose freedom to be able to do such things like trying to be extra-protective against misuses.

[Sebiee]

Sorry, you are right. It was a bad explanation. The reason of obtaining the same ID is that the configure() is overriding the command line specified libcxx, so the libstdc++11 binary is the one always used. If you remove some settings in the configure(), they should also dissapear from package ID.

Ok, I understand that removing settings, counts for the package ID. I too agree with not making the settings read-only because of the reasons you specified.
But this being said, I still see a problem with the thing that I request all my requirements packages to be built with libstdc++, but conan gives me a package that was built with libstdc++11 and even it is specified in the package info as having been built with that setting.
To be clearer:
I build a library A through a recipe with settings modified in the configure method,
self.settings.compiler.libcxx="libstdc++11"
The package built is 412f for example.

I want to build an app B that depends on lib A. I want to build it with
conan install .. -s compiler.libcxx="libstdc++"
and conan says, _ok, for requirement A I have the package 412f for you_.
Recipe for app B does not modify the settings in the configure method.

Is this scenario seen as normal? I still see a problem because conan gives me a package which conan itself tells me that it has different settings than I requested.(see pic).

PS: Should the documentation be updated too? I see that it says that you the configure method is the right place to modify settings. http://docs.conan.io/en/latest/mastering/conditional.html

[memsharded]

Is this scenario seen as normal? I still see a problem because conan gives me a package which conan itself tells me that it has different settings than I requested.(see pic).

Yes, even if the settings are considered "project-wide", it is still possible to specify settings per-package. Something like:

$ conan install . -s compiler="Visual Studio" -s MyPkg:compiler=gcc

Also in profiles. In some exceptional occasions, users want to be able to define some particular settings values for some packages in the dependency graph, which sometimes makes sense (e.g. building some shared library with C linkage, with an special compiler, even a different compiler like fortran).

So the settings values are per-package. If one package LibA hardcodes to use libstdc++11 in its recipe, that is totally decoupled of what consumer AppB is doing in its configure with its settings.

Yes, you are right, the documentation has to be improved in that section, thanks for pointing out.

[memsharded]

Updated docs in: https://github.com/conan-io/docs/commit/d5227837ab31d077805d28e91abc613ea59840f7

[Sebiee]

Ok then.
If LibA hardcodes libstdc++11 in its recipe, and I want to build AppB with:
conan install . -s LibA:compiler=gcc -s LibA:compiler.libcxx=libstdc++
I still think that somehow it would be nice that I would be informed that the package of LibA given to me does not have the settings I desired.

[memsharded]

Because what you are doing is specifying in your recipe that your package will work irrespective of the input setting. What should be done if the package recipe removes libcxx? This is done for every pure C library package, because it will not depend on the C++ std lib. What if the package defines in its package_id() that self.info.compiler.version=4.X, instead of the given 4.8 or 4.9 gcc version? It is the choice of the package recipes to ignore, remove, use or not the settings.

Warning the user about every potential misuse in conan recipes would generate tons of false positives, which will be confusing and annoying for most users. Making an opt-in argument for those diagnostics is yet another feature to implement, document and maintain, which most users won't learn anyway, and they might be landing in this issue before landing in the docs page for that opt-in argument.

I understand your concern, but we also have to weight very carefully each extra feature added to the codebase, and this one is not an obvious one and the benefit might be marginal.

[jcar87]

Am I correct in describing that the issue is the following?

• Conan build recipe for libA does this in the configure() method:
  self.settings.compiler.libcxx="libstdc++11" ,
• libA is built (which libcxx value was specified when building it?? - not sure if relevant)
• Doing this conan install . -s LibA:compiler=gcc -s LibA:compiler.libcxx=libstdc++ points to the same hash as the library built with libstdc++11 , and that's not what you expect?

As mentioned earlier, I dont think the intention of configure() is to overwrite input values like that. The way I typically see it, is that settings/options present (or rather, present after configure() has been called) mean that a different package ID will be created for any set of values (of all options and settings). By "removing" an option or setting in configure(), we are telling conan that the same package will be built regardless of the value of the setting/option that we just removed. At least that's how I understood it.

I wouldn't 'overwrite' the value of libcxx. If the package produces the same binaries regardless of libstdc++ / libstdc++11, use the package_id() method to specify that. As far as I understand, the CXX11 ABI is only an issue when std::string or std::list cross library boundaries.

[Sebiee]

Conan build recipe for libA does this in the configure() method:
self.settings.compiler.libcxx="libstdc++11"

Yes

libA is built (which libcxx value was specified when building it?? - not sure if relevant)

Not relevant since it will always end up being libstdc++11

Doing this conan install . -s LibA:compiler=gcc -s LibA:compiler.libcxx=libstdc++ points to the same hash as the library built with libstdc++11 , and that's not what you expect?

Yes.
conan install . -s LibA:compiler=gcc -s LibA:compiler.libcxx=libstdc++
and
conan install . -s LibA:compiler=gcc -s LibA:compiler.libcxx=libstdc++11
point to the same LibA package hash.

By "removing" an option or setting in configure(), we are telling conan that the same package will be built regardless of the value of the setting/option that we just removed. At least that's how I understood it.

Yes, I understood that way too. Fact is that if you also modify a setting in the configure() method, conan understands the same as when removing it. If @memsharded agrees that that's the case, it would be nice if something about removing settings would be written in the documentation also.

Conclusion of this issue would be that I used the settings the wrong way.

Thank you for taking time in explaining this and for updating the documentation.