Conan: What causes error message: ERROR: <pkg-name> 'settings.arch' value not defined?

Created on 17 Aug 2018  路  17Comments  路  Source: conan-io/conan

Conan 1.6.1

Hi,

We have a structure like the following (simplified):

PkgA requires PkgB
PkgB requires PkgC

PkgA has no settings attribute
PkgB has _settings = "os", "compiler", "build_type", "arch"_
PkgC has no settings attribute

if we run (for PkgA):

conan install PkgA-recipe -if <build dir>
conan build PkgA-recipe -bf <build dir> -sf <src folder>
conan export-pkg PkgA-recipe dev/test -bf <build dir>

we get the error _ERROR: PkgB 'settings.arch' value not defined_. The output from conan suggests that the _conan export-pkg_ command successfully exporting the package, but failed before the package() method is called.

if we run (for PkgA):
conan create PkgA-recipe dev/test

it works fine.

To stop the error for the local build we added _settings = "os", "compiler", "build_type", "arch"_ to PkgA but we don't understand why this was required.

Any guidance on what we may have done wrong?

bug

All 17 comments

It might be a bug, thanks for reporting, we are going to investigate.

Reproduced, certainly unexpected behavior, labeling as bug and trying to fix it for 1.7

Hi @keithrob91

I have been working on this, but is more complex than expected. Will continue working for 1.8, but don't have time in conan 1.7.

In the meantime, please use one of the following workarounds:

  • Add the settings to the header only recipe, as you did. Remember to add self.info.header_only() to the package_id() of your header only recipe conanfile.py
  • Use a normal conan create to package the header only. It will be very fast too, and the recipe will be extremely simple. conan export-pkg actually only makes full sense if you are creating binaries outside of the conan-cache, but for header only it is not a thing.

OK, thank you for update. We've gone for the first option

hi

i came across an issue with conan info failing with a package having the cmake_installer as build_requires:

$ conan info ..
ERROR: cmake_installer/3.12.2@myuser/mychannel: 'settings.arch_build' value not defined

Of course arch_build is defined in the settings.yml and set correctly in the default profile to x86_64. Installing the cmake_installer/3.12.2@myuser/mychannel package incl. the correct binaries works as well.
conan info -s arch_build=x86_64 .. also works though arch_build=x86_64 is already set in the default profile:

$ conan profile get settings.arch_build default
x86_64

Could this be caused by the same bug? Is there a possible workaround?

Hi @keithrob91

We are proposing the following solution in https://github.com/conan-io/conan/pull/3768

The information stored in the conan install in conaninfo.txt is not enough for all cases. So we are allowing to specify the profile also in the conan export-pkg. It will be released in conan 1.9. With that fix, you will be able to remove the hacks from your conanfile.py recipe.

We will also try to propose a new mechanism, so the information captured at conan install is more complete, but that would be breaking now, so it is planned for conan 2.0 https://github.com/conan-io/conan/issues/3769

Isn't the -pr argument already accepted for conan export-pkg (1.8.2)? I'm a little confused!

Not yet. It is a change big enough to be in next 1.9 release, not in the 1.8.2 patch.

You can see the PR with the changes https://github.com/conan-io/conan/pull/3768 for 1.9 milestone

conan help export-pkg reports -pr as an option though (in 1.8.2)?

--profile options is used currently only when there is no conaninfo.txt file present in the installation directory. For example, if you run the local commands and then try to conan export-pkg, it will use the info in the conaninfo.txt.

The PR mentioned before changes that behavior to always use the profile or settings if specified.

Oh I see. My only comment then is that the documentation did not make that clear.

Thank you for the information and updating me on the fix.

--profile options is used currently only when there is no _conaninfo.txt_ file present in the installation directory. For example, if you run the local commands and then try to conan export-pkg, it will use the info in the conaninfo.txt.

The PR mentioned before changes that behavior to always use the profile or settings if specified.

This should be added to the documentation. I read through the profile section and it's not mentioned.
I was wondering why I was getting issues with my settings not being set even though I have a conanfile.py in my project.

Hi @ManuelMeraz

Do you mean that the last paragraph of https://docs.conan.io/en/latest/reference/commands/creator/export-pkg.html is not clear enough of this behavior?

This section is however getting a partial re-write in https://github.com/conan-io/docs/pull/1232. Maybe you could please check that PR and see if it is more clear now, or if that PR could be further improved to account for this. Thanks!

Hi @ManuelMeraz, please have a look at the attached PDF file, I've rendered it for you from the PR #1232. Let me know if the text describing the command and/or the note at the end is clear enough or it can be improved somehow, thanks:

conan_export_pkg.pdf

image

Sorry for the late response.

That wasn't exactly my problem, and mostly it was due to my ignorance probably.

My problem was in my project I had a conanfile.py that I wanted to use, and I wanted to create "profiles" that had slightly different settings, but it would still use the settings in my conanfile, except the settings changed in my new profile. Such as compiling with a specific version of clang. I wanted to keep them within a hidden .profles directory so I could use them with travis.

Example:
conan install --install-folder build --build --profile ./my_profile

In my mind this would:

  1. Configure my cmake inside the folder called build
  2. Build from source
  3. Use the profile settings in my_profile and override the settings that are changed in my conanfile

In my_profile I would only have something like

[settings]
compiler = clang
compiler.version = 6.0
compiler.libcxx = libstdc++11

Because I wanted to use clang to compile my code, and not gcc.

This was not how this works, what happens is that only the my_profile is used, and conanfile.py is completely ignored. I would get an error something like:
settings.arch not set

Which confused me.

So, to get the behavior I needed, I needed to create my own profiles and put them in ~/.conan/profiles, which seemed to do the trick.

It was not so simple to figure out how to compile with clang. Still, I want to think about porting my profiles with my project and not have them in my home directory.

Hi, @ManuelMeraz!

See your issue, do you know you can compose profiles or even pass several of them to the same command?

Take a look at Profile includes, if your profile is defined in the file my_profile (in your local folder) it can include a _default_ one:

include(default)
[settings]
compiler = clang
compiler.version = 6.0
compiler.libcxx = libstdc++11

and also at profile composition, you can pass several profiles to the same command:

conan install ....  -pr=default -pr=my_profile

Yes! I knew about that, but the way you just showed me in that exampled makes it very clear that it is perfect for my use case. I never thought about applying that to my specific case.

I can do what I was originally doing, I just need to include the default one and those settings will then be defined. Perfect. That is exactly what I needed :). Thank you.

Was this page helpful?
0 / 5 - 0 ratings