Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[bug] [lockfiles] ERROR: Build-require 'nasm' cannot be found in lockfile #13162

Closed
BoilerTom90 opened this issue Feb 18, 2023 · 4 comments
Closed

Comments

@BoilerTom90
Copy link

BoilerTom90 commented Feb 18, 2023

Environment details

  • Operating System+version: Windows 10
  • Compiler+version: Visual C++17
  • Conan version: 1.58.0
  • Python version: 3.10.7

Steps to reproduce

Running the conan install command shown below yields the error in the title of this issue.

$ ls conan*
conan.base.lock  conan.lock  conanfile.txt
$ conan install . --update --build missing --lockfile conan.lock
Using lockfile: '<path>\build\conan.lock'
abseil/20211102.0: WARN: Can't update, no package in remote
ERROR: Build-require 'nasm' cannot be found in lockfile

I'm confused because the nasm entry is in the lockfile. I saw two similar conan tickets (10345, 10544) about this issue, but in both of those cases, the issue I believe was the build requires dependency was also a regular requires dependency. I don't think that's my issue. nasm is only a build_requires dependency.

Pertinent section of conanfile.txt

nasm/2.15.05#799d63b1672a337584b09635b0f22fc1
b2/4.9.3#5445210661950ce568cfd76158d9e117
strawberryperl/5.30.0.1#d125df083747d815c66e9ee621f3909f

Pertinent sections of conan.lock

nasm is 29

    "requires": [ 
     ... 
    ],
    "build_requires": [
     "29",
     "30",
     "31"
    ],

   "29": {
    "ref": "nasm/2.15.05#799d63b1672a337584b09635b0f22fc1",
    "options": "",
    "package_id": "01edd76db8e16db9b38c3cca44ec466a9444c388",
    "prev": "bc150d26d6dde7a726c4b39a62cecab8",
    "context": "host"
   },
   ...
}

Complete conanfile.txt and conan.lock files:

conanfile.txt
conan.lock.txt

Interesting Data Point ...

Our conan install used to work with the same set of dependencies. when it works, we were not explicitly specifying the build_requires dependencies. We just let conan figure that out. Also, when running conan install, we were using the conanfile.txt instead of a conanlock file. We want to use the conan lock file so we can lock in the versions and recipes for dependencies and transitive dependencies. So, I don't know if the root issue is installing with a conan lock file, or explicitly specifying the build_requires section, or a combination of both.

Logs

Entire output from running conan install:

$  conan install . --update --build missing --lockfile conan.lock
Using lockfile: '<path>\build\conan.lock'
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Debug
compiler=Visual Studio
compiler.cppstd=17
compiler.runtime=MDd
compiler.version=17
os=Windows
os_build=Windows
[options]
[build_requires]
[env]

abseil/20211102.0: WARN: Can't update, no package in remote
ERROR: Build-require 'nasm' cannot be found in lockfile
@memsharded
Copy link
Member

Hi @BoilerTom90

Thanks for your question.
This seems a weird error, but it is true that lockfiles in Conan 1.X are challenging, and have some known rough edges. This is why we are really excited about lockfiles in 2.0, they will surely solve these issues.

Quick question about your reported case: is the lockfile captured for the same recipe/package that is being used later to apply that lockfile? Because one possible cause could be applying a lockfile to a different package in the graph. Lockfiles in 1.X capture the whole graph, with the relations. When applied to a different package in the graph, it might be difficult to find the matching reference in the lockfile, and this could be causing the issues.

@BoilerTom90
Copy link
Author

BoilerTom90 commented Feb 19, 2023

@memsharded

Here's how the lock file was created:

This is actually part of a CMake environment, and I'm using conan.cmake. My CMake script does the following:

  1. I invokeconan_cmake_configure to create conanfile.txt

I'm providing all the arguments that you saw in the generated conanfile.txt that is included with this issue.

  1. I invoke conan_cmake_lock_create to create a base lock file

I'm doing this is because we want to lock in versions and recipes for all dependencies and transitive dependencies, but not include the build/host information.
Eventually, this would be the file we check into our VCS for repeatable builds.

  1. I invokeconan_cmake_lock_create to create a lock file to use for installation.

this lock file uses the conanfile.txt and the base lock file created in the prior step. I'm also passing --update, and --build missing.
This is the lockfile included in this issue and contains the build/host info.

  1. I invokeconan_cmake_install to install the packages:

The arguments I'm passing are the same as the example provided in this issue.

I'm not sure I answered your question, but I believe the answer to your question is yes, same version and recipe...

but as I pointed out above, I find it interesting that I can invoke conan install w/out the lockfile option and it works. But as soon as I use the lock file option, which was generated from the same conanfile.txt file, it fails with the missing build-require error.

I was reading up on conan 2.0 and lock files. Since we're using conan as consumers from within Cmake, we make use of conan.cmake. I got the impression there currently isn't a conan.cmake yet in the works for conan 2.0. That's going to make it difficult to migrate to 2.0.

@mjb6
Copy link

mjb6 commented Feb 21, 2023

Might be related to #12719

@memsharded
Copy link
Member

Sorry this was not followed up back then.

This referred to old Conan 1.X lockfiles. Lockfiles have been fully revamped in Conan 2.0, I am closing this ticket as outdated, please create new tickets referring to the new lockfiles for any further question or issue. Thanks!

@memsharded memsharded closed this as not planned Won't fix, can't repro, duplicate, stale Jan 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants