cargo-build-bpf: Running from top-level workspace still filters targets on Xargo.toml

[joncinque]

Problem

Although Xargo.toml is no longer needed with the new build system, cargo build-bpf still filters for bpf packages based on the presence of Xargo.toml when building at the workspace level:

solana/sdk/cargo-build-bpf/src/main.rs

Line 404 in e488922

package.manifest_path.with_file_name("Xargo.toml").exists()

Proposed Solution

I'm not sure to be honest, so a few mediocre ideas:

• build-bpf can just try to build everything the workspace
• programs specify [build.target] in Cargo.toml to target bpfel-unknown-unknown
• programs add a feature like build-bpf, similar to test-bpf (or just use test-bpf, but that feels even worse)

[mvines]

Darn. I guess for now keeping Xargo.toml around isn't terrible, even though it's now only for build-bpf

[joncinque]

Looks like this was done in #16431 by Jack, searching for a cdylib target -- thanks @jackcmay !

[jackcmay]

My solution may not hold up forever if there is a non-bpf compatible project in the workspace that also exports a cdylib , but for now I think it is better than requiring folks to create xargo.toml files. We could flag a project as bpf compatible via a package.metadata field instead. https://doc.rust-lang.org/cargo/reference/manifest.html#the-metadata-table

[mvines]

solana-program dependency + cdylib is a pretty strong signal