Cargo pulling in source dependencies even when the source feature is disabled

[bkirwi]

For example, this section means that compiling for a linux target will always require fontconfig to be available, even when the source feature is not enabled: https://github.com/servo/font-kit/blob/master/Cargo.toml#L61-L62

This means that eg. cross-compiling becomes more difficult, since you now need fontconfig compiled for the target system, even though you don't intend to use it.

[jdm]

The fact that the dependency is pulled in is a limitation of cargo. However it will only be built if it's part of the active dependency graph based on the features selected, since it's marked as an optional dependency.

[bkirwi]

However it will only be built if it's part of the active dependency graph based on the features selected, since it's marked as an optional dependency.

Heartbreakingly, I don't think this is quite right in practice.

yeslogic-fontconfig-sys is listed twice in Cargo.toml, once as an optional dependency, and one as a normal dependency for systems that match cfg(not(any(target_family = "windows", target_os = "macos", target_os = "ios", target_arch = "wasm32"))). The source feature -- which requires yeslogic-fontconfig-sys to build correctly! -- has no dependencies in the Cargo.toml at all, on yeslogic-fontconfig-sys or anything else.

This is visible in the build output when compiling on Linux:

bkirwi@bkirwi-2023:~/Code/font-kit$ cargo build --no-default-features
[...]
   Compiling yeslogic-fontconfig-sys v5.0.0

This passes on my Linux dev machine, where fontconfig is available... but on my embedded system, where it is not available, I get:

error: could not find system library 'fontconfig' required by the 'yeslogic-fontconfig-sys' crate
Package fontconfig was not found in the pkg-config search path.
Perhaps you should add the directory containing `fontconfig.pc'
to the PKG_CONFIG_PATH environment variable

If I comment out the previously-linked section of Cargo.toml, though, it passes.

[jayvdb]

I believe that due to rust-lang/cargo#1197 , and the auto-backend-selection approach for font-kit , the only way this issue might be fixable is to introduce an extra package, e.g. "font-kit-core" which has all the current code.

Then font-kit would add dependency font-kit-core with different features enabled per target.
Even then I am not sure it would work, as this issue is about deselecting a platform specific default dependency.

[jayvdb]

#180 is related to splitting off source related features to a separate crate.