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

build package does not work with cargo resolver 2 #45

Open
webern opened this issue Aug 30, 2023 · 0 comments
Open

build package does not work with cargo resolver 2 #45

webern opened this issue Aug 30, 2023 · 0 comments
Labels
bug Something isn't working

Comments

@webern
Copy link
Contributor

webern commented Aug 30, 2023

Description

bottlerocket-os/bottlerocket#3372 (comment)

Running cargo make -e PACKAGE=libfoo build-package results in running cargo build --manifest-path variants/Cargo.toml --package libfoo. This reproduces the error a little faster.

The key to understanding the error lies in the new Cargo feature resolver v2 separating activated features by both package and where/when it is going to be used. When checking for activated features of a package, Cargo takes both into account. It bails when it unexpectedly cannot find a combination of {package, where to use it}.

The following is my current understanding of the matter, but it is to be taken with a grain proper amount of salt:
We are using dependencies and build-dependencies in the Cargo manifests for specifying runtime and buildtime dependencies both for the target architecture which is a bit different from what Cargo uses these for. Specifying a dependency in the build-dependencies section of a manifest, I believe, activates features in this dependency package as HostDep. When:

a variant is built, the roots of all (RPM) package trees to pull into the final image are likewise defined as build-dependencies (e.g. in variants/metal-dev/Cargo.toml). When resolving the feature set for dependencies upon building these top-level packages (already known as HostDeps), Cargo looks for and finds their (and their transitive) dependencies also as HostDep.
when just building a single package it is looking for activated features in a NormalOrDev context for the single target to be built (e.g. libfoo)--while still knowing libfoo and all of its dependencies as HostDep only.
I'm not sure what would a good way to resolve this would look like. Perhaps reverting to the feature resolver v1 and accepting warnings is the lesser evil for now, so we can avoid the problem by having the unified feature namespace.

Definition of Done

When Bottlerocket and any other Twoliter project can use build package with workspace resolvers set to v2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant