minimal-versions: freetype-rs dependency is too low

[Drakulix]

Compiling crossfont with -Z minimal-versions fails with:

error[E0425]: cannot find function, tuple struct or tuple variant `FT_Set_Default_Properties` in crate `freetype_sys`
   --> /home/drakulix/.cargo/registry/src/github.com-1ecc6299db9ec823/crossfont-0.4.0/src/ft/mod.rs:674:27
    |
674 |             freetype_sys::FT_Set_Default_Properties(library.raw());
    |                           ^^^^^^^^^^^^^^^^^^^^^^^^^ not found in `freetype_sys`

I assume crossfont needs a higher freetype-rs version than the minimum specified in the Cargo.toml, because running cargo update -p freetype-sys fixes the error.

[chrisduerr]

I can't actually reproduce this? Building crossfont and Alacritty works for me just fine with -Z minimal-versions. Both on 0.4.0 and on 0.4.1.

[Drakulix]

0.4.1 is even worse for (I was testing with 0.4.0 accidentially, because that is the minimum version sctk-alacritty depends on):

crossfont on  HEAD (1cd57dc) is 📦 v0.4.1 via 🦀 v1.59.0 
❯ cargo +nightly -Z minimal-versions update
    Updating crates.io index
    Updating crossfont v0.4.0 (/var/home/drakulix/Projects/tavern/crossfont) -> v0.4.1

crossfont on  HEAD (1cd57dc) is 📦 v0.4.1 via 🦀 v1.59.0 
❯ cargo +nightly -Z minimal-versions check
   Compiling crossfont v0.4.1 (/var/home/drakulix/Projects/tavern/crossfont)
error: cannot find macro `log` in this scope
  --> src/ft/fc/font_set.rs:52:9
   |
52 |         trace!("Number of fonts is {}", num_fonts);
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: `log` is in scope, but it is a crate, not a macro
   = note: this error originates in the macro `trace` (in Nightly builds, run with -Z macro-backtrace for more info)

error: cannot find macro `log` in this scope
  --> src/ft/fc/font_set.rs:65:9
   |
65 |         trace!("Number of fonts is {}", num_fonts);
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: `log` is in scope, but it is a crate, not a macro
   = note: this error originates in the macro `trace` (in Nightly builds, run with -Z macro-backtrace for more info)

error: cannot find macro `log` in this scope
   --> src/ft/mod.rs:177:21
    |
177 |                     trace!("Using fallback strikeout metrics");
    |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: `log` is in scope, but it is a crate, not a macro
    = note: this error originates in the macro `trace` (in Nightly builds, run with -Z macro-backtrace for more info)

error: cannot find macro `log` in this scope
   --> src/ft/mod.rs:711:13
    |
711 |             trace!("Got font path={:?}, index={:?}", ft_face_location.path, ft_face_location.index);
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: `log` is in scope, but it is a crate, not a macro
    = note: this error originates in the macro `trace` (in Nightly builds, run with -Z macro-backtrace for more info)

error: cannot find macro `log` in this scope
   --> src/ft/mod.rs:753:13
    |
753 |             debug!("Loaded Face {:?}", face);
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: `log` is in scope, but it is a crate, not a macro
    = note: this error originates in the macro `debug` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0425]: cannot find function, tuple struct or tuple variant `FT_Set_Default_Properties` in crate `freetype_sys`
   --> src/ft/mod.rs:680:27
    |
680 |             freetype_sys::FT_Set_Default_Properties(library.raw());
    |                           ^^^^^^^^^^^^^^^^^^^^^^^^^ not found in `freetype_sys`

For more information about this error, try `rustc --explain E0425`.
error: could not compile `crossfont` due to 6 previous errors

I have attached the Cargo.lock generated on my system, hopefully that helps?

Cargo.lock.txt

[chrisduerr]

Huh it works now, by which I mean it doesn't build. I must have forgotten to delete the Cargo.lock yesterday.

That said, do you actually have suggestions to fix this issue specifically? Of course we should have minimal versions in our dependency tree that actually build, but that doesn't help you, right? Or do you plan to just bump the patch version to 0.4.3, despite technically being able to build with 0.4.2 too?

[Drakulix]

What I want to get out of this is being able to build smithay with minimal-versions, which mean this fix would have to propagate through to winit...

• crossfont would need to update the minimal versions of log and freetype and release 0.4.2.
• afterwards sctk-adwaita would need to depend on crossfont 0.4.2 and also publish a new version.
• and finally winit could update the minimum required sctk-adwaita version (hopefully in time for the next release).

(I could instead disable the sctk-adwaita feature of winit, but that is not the core of this issue here. If you have the time and energy, I would recommend also setting up CI for this in winit at least.)

Also yes: Technically we can build with 0.4.1, the code is not wrong. What is wrong are its dependencies so in my opinion we cannot actually build with 0.4.1 and bumping the patch version is the correct fix.

[chrisduerr]

in my opinion we cannot actually build with 0.4.1

Considering Rust's stance on running with minimal versions, I'd consider this inaccurate. Generally I think you're going to have a tough time getting a guarantee to always be able to build with minimal versions.

While the log crate was specified incorrectly by crossfont for example, it is necessary to patch freetype to fix the other issue (I've sent servo/libfontconfig#66 to resolve it for now).

[Drakulix]

Considering Rust's stance on running with minimal versions, I'd consider this inaccurate. Generally I think you're going to have a tough time getting a guarantee to always be able to build with minimal versions.

In practice this is true, but I want to try and encourage more people to fix this in their crates.

While the log crate was specified incorrectly by crossfont for example, it is necessary to patch freetype to fix the other issue (I've sent servo/libfontconfig#66 to resolve it for now).

Thanks for forwarding this as necessary.

[kchibisov]

Should be fixed.