How to build with non-default crate features?

[Victor Bankowski]

Hello!

We are trying to use dinghy to cross-compile and run benchmarks on android (and on the raspberry pi in the future).

Previously we have built the project with the following command:

cargo build --target aarch64-linux-android --release --lib --no-default-features --features "android_build"

As you can see we disable default features and enable the "android_build" feature. This is because there are certain dependencies in our project that won't work on android and we also have some dependencies that are only needed for android.

I've tried to run the benchmarks with all of these:

cargo dinghy -d android bench --no-default-features --features "runtime/android_build"
cargo dinghy -d android bench --no-default-features --features runtime/android_build
cargo dinghy -d android bench --no-default-features --features "android_build"

But they all cause the error message:

[2021-01-21T12:29:36Z ERROR cargo_dinghy] cargo does not support --features flag when building from root of workspace

The project isn't a workspace so it seems like dinghy makes it a workspace to perfom the builds. How do I enable or disable crate features when using dinghy?

[Mathieu Poumeyrol]

We will have to look into this. I think I remember we tried it in the past, but encountered some serious problem working around cargo limitations (hence the message). But it may have changed now, so it may be worth revisiting.

One way to help, if you want this to move faster, would be to extend test-ws (and maybe add a text-app at the top level if it becomes relevant) illustrating what you are trying to achieve and give us as many cargo dinghy invocation using features for coverage.

[Brian Smith]

Perhaps the mechanism I suggest in issue #210 would be useful here, since the user would use their normal cargo bench command instead of cargo dinghy bench.

[Thibaut Lorrain]

As a matter of fact, since version 0.5.0 and the big refactoring done in #157, this is fixed.

Pre 0.5.0 we redefined the whole cli for all supported cargo commands, which leaded to this sort of inconsistencies, as we bundled a version of cargo inside dinghy and launched the various commands we the programming api. This is not the case anymore as we no pass the args directly to the cargo cli

(I just retested this exact case to be sure, it is definitely fixed)