Custom features no longer affect the build

[jdm]

When I write ./mach build -d --features whatever, I no longer receive an error about the whatever feature not existing. If I add -v to the build, I don't see whatever passed to any of the crates. This regressed sometime in the past month.

[highfive]

cc @wafflespeanut

[jdm]

The actual build command being invoked is rustup run --install nightly-2018-07-17 cargo build -v --features whatever, so I'm really confused why this is being ignored now.

[jdm]

I believe this was regressed by #20912, which removed the use of --manifest-path from the cargo commands. When I create a workspace with a single default-member, cargo build --features whatever no longer produces an error. When I run cargo build --manifest-path project --features whatever (assuming the default member is named project), I receive the expected error.

cc @SimonSapin

[jdm]

This also means that we can't use --debug-mozjs, or any of the VR-related features.

[jdm]

I've filed rust-lang/cargo#5849.

[jdm]

@SimonSapin Are you aware of a workaround here? Could we restore the previous manifest-path usage that existed before #20912?

[SimonSapin]

I’m not sure exactly. I think that reverting to using --manifest-path in mach would fix command-line usage of --feature, but then we’d need to find another way to deal with libsimpleservo v.s. the servo executable. Perhaps the former should not be in default-members after all, and instead we should have (more) custom logic in mach for Android targets.

[jdm]

Simon said they would work on this.

[SimonSapin]

Using --manifest-path means picking one "root" crate to build, whereas the current default is to build both ports/servo and ports/libsimpleservo.

@paulrouget What do you think of building the latter for Android targets and the former in other cases? Are there cases where we want to make the other choice? Specifically, since ports/servo is an empty crate on Android, do we want to support (building) libsimpleservo on non-Android? Would ./mach build --manifest-path ports/libsimpleservo be an acceptable interface for that?

[jdm]

We could do something like the old ./mach build-geckolib, too. We're relying on being able to build libsimpleservo for ML devices, but those aren't detected as android devices.

[SimonSapin]

What are ML devices in this context?

[paulrouget]

@SimonSapin libsimpleservo is not android specific (there's a non-jni version too), even though we only use it for Android now. We need to be able to build both ports.