#[cfg(feature)] not working

help
1

I have this code:

#[cfg(feature = "some_feature")]
let some_variable = SomeType::new();

but the compiler complains that some_variable is not in the current scope when I try to use it.

edit: I also have the feature set in my vscode settings.json and tried to pass it via command line argument as well.

2

I need to see more of the code to understand what you are trying to do. (at least enough to see where you use the variable, preferably more)

3

This is the code basically:

fn some_function() -> SomeType {
    #[cfg(feature = "some_feature")]
    let some_variable = SomeType::new();

    some_variable
}
4

Right, but it doesn't make sense to have code like that which can only compile with the feature enabled (because then why does the feature even exist? You can't disable it!). So I assume you must be trying to use #[cfg(feature)] where you should be using something else.

To be clear: The purpose of #[cfg(feature)] is to make parts of your code optional. Stuff tagged with cfg(feature) disappears from the code when somebody depends on your library and doesn't enable the feature.

To probe a bit further: What kind of feature is this? Is it a feature you provide to consumers of your crate? Is it an unstable feature (like euclidean_division)? Did the docs of one of your dependencies say that such-and-such feature is required to use some function?

5

I want to use it to switch between different implementations of a type
like this:

fn some_function() -> SomeType {
    #[cfg(feature = "A")]
    let some_variable = SomeTypeA::new();
    #[cfg(feature = "B")]
    let some_variable = SomeTypeB::new();

    some_variable
}
6

Okay. How are you enabling it from the command line?

7

I also have the feature set in my vscode settings.json and tried to pass it via command line argument as well.

8

No, tell me the command you used.

9

settings.json:

{
    "rust.features": [
        "vulkan"
    ]
}

cargo build --feature=A

10

What is your project structure? Do you have more than one Cargo.toml file? (e.g. one for a library crate and one for a binary that depends on it)?

11

Yes, it's a workspace with one lib and one bin

12

What happens if you:

  • go to the lib and cargo build --features vulcan
  • go to the bin and cargo build --features vulcan

(it's okay if your answer to one of these is that that particular crate doesn't have the feature)

1 Like
13

Thanks it works. thought it would be enough to add the feature when building the workspace
Edit: Do you know if I can achieve this with my settings.json in vscode?

14

Well, I'll be! That wasn't supposed to be the solution! :stuck_out_tongue:

So both of these can be compiled in their own right? In that case, you can achieve what you want in a manner by adding a feature to the workspace. If your workspace only has a virtual manifest (i.e. a [members] table), try turning it into a full package by adding a [package] table, and replacing the members with path dependencies:

[dependencies]
the-lib = { path = "path/to/lib" }
the-bin = { path = "path/to/bin" }

Then you can add features to the root package that recursively enable features on the other crates.

[features]
vulkan = ["the-lib/vulkan", "the-bin/vulkan"]

If you go this route you'll need to add a dummy lib.rs for the root package (or alternatively you can try to turn either the lib or the bin into your workspace root. Probably the bin since I imagine it already depends on the lib?).

1 Like
15

Thanks, I'll try that
Edit: I found another solution.
I can specify the features for my lib in the Cargo.toml of my bin crate

16

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.