(Optionally) work with fontconfig-sys instead of servo-fontconfig-sys

[ashkitten]

I'm trying to use font-loader with glium_text, which uses fontconfig-sys. If I try to use them both at once, it gives me error: native library `freetype` is being linked to by more than one package, and can only be linked to by one package. Would it be feasible to make it at least optionally work with fontconfig-sys?

[matprec]

Yeah, i don't like the current solution either.

Ideally, font-loader shouldn't use servo-fontconfig-sys, since it compiles and links fontconfig. I don't now whether or not there are people depending on it, so i propose a two step migration:

1. Introduce fontconfig-sys behind a feature flag instead of servo-fontconfig-sys. Conditional compilation makes it possible to avoid linkage. Introduce a dead code block in servo-fontconfig-sys block, which says somethin along the lines of "dependency will change, use new flag now, see issue #blah". This way, people will be warned.
2. Somewhere in the future, drop servo-fontconfig-sys completely

If you need help, let me know!

[ashkitten]

Any progress on this? If you need a PR let me know

[matprec]

Sorry for the delay!

If you could provide the PR, that'd be perfect. I don't have that much time on hand, so if you could provide a PR, that'd be perfect! If you have problems/no time on your own, let me know. We will find a way to solve this :)

[ashkitten]

Looks like until rust-lang/cargo#1197 is resolved, we won't be able to introduce a platform-specific dependency behind a feature flag.

[ashkitten]

er, looks like it works fine by putting it in the regular [features] section. never mind :)

[matprec]

Wouldn't it still pull servo fontconfig and therefore fail at linktime? Another relevant bug: rust-lang/cargo#2524

[ashkitten]

hmm, it also looks like fontconfig-sys is too old... doesn't work with rust 1.0 it seems? i'm not sure what our options are here

[matprec]

I see two options:

1. Explain your issue to the servo-fontconfig(-sys) project and make the build of fontconfig optional, via feature flag.
2. Approach the glium_text project and explain your issue, point on fontconfig being outdated, propose switching to servo-fontconfig and ideally provide a patch witch does it.
   (3. Use bindgen and publish your own fontconfig crate)

[ashkitten]

I've already decided to move to freetype-rs from glium_text, but I might be able to do something about it. @jwilm solves this in https://github.com/jwilm/alacritty/tree/master/font by using a custom version of rust-fontconfig that uses piston's bindings instead, so that might be an option as well.

[matprec]

You could also try to override font-loaders servo-fontconfig dependency, given that the replacement has the same structure (use statements would become invalid)

[jwilm]

It would be nice if the community could rally around a single fontconfig-sys and freetype-sys crate which allow fontconfig to optionally link with freetype. This is actually blocking me from publishing some high-level fontconfig bindings used in Alacritty. Would need buy-in from both Servo and Piston. No idea if the problem is technical or political, or just nobody bothered to talk in the first place.

I believe if that happened, all of these issues could go away, and Rust + Linux font stack would be much better off.

@ashkitten FWIW, I've had basically zero problems with the approach in Alacritty.

[ashkitten]

I decided to go with that approach in my application. I only had to fork servo-fontconfig-sys, since I can just use the [replace] section in my Cargo.toml

[ashkitten]

It seems to me like this issue doesn't really accomplish anything, so I'll close it now.