smithay-client-toolkit fails 1.24.1 Linux builds

[Osspial]

The root cause seems to be from stb_truetype, which is depended on by smithay-client-toolkit via andrew via rusttype.

[elinorbgr]

Yes, some of our dependencies have made patch versions upgrades breaking rustc compatibility, however SCTK remains 1.24.1 compatible if these dependencies are forced to their older versions.

We are testing this in our travis script, like so: https://github.com/Smithay/client-toolkit/blob/6538cab77a6bde08d6784f8f1ebe818de38e0045/.travis.yml#L61-L68

This way, SCTK can remain its rustc compatibility without locking itself out of dependencies updates. I guess we could do the same thing for winit?

[Osspial]

We could. I'm not sure if that's really in the spirit of guaranteeing 1.24.1 compatibility, though - I read it as "you can download a copy of this library off crates.io and use it with 1.24.1 with no extra steps", which that doesn't really do.

[elinorbgr]

Well, I see mostly two ways of dealing with that:

• Fixing exactly the dependencies version, opting out of all updates. This has the obvious downside that you cannot profit from any more recent bugfixes, even if you use a more recent rustc. And can lead to unnecessary duplication of dependencies in the final application.
• Not fixing the dependencies version, meaning that the final user has to manage the versions of some of its dependencies to ensure compilation with their version of rustc. On this side, I'd argue that a project that fixes its rustc version to some older one than the current stable will already have some precise handling of its Cargo.lock, and thus the added discomfort would not be very big.

Though, it is absolutely possible to fix the versions of these dependencies in winit's Cargo.toml to override SCTK's looser dependency specification.

[francesca64]

I agree with @Osspial that superficially making the CI pass isn't in the spirit of maintaining compatibility. I've created an issue on stb_truetype that will hopefully lead to an elegant resolution.

[elinorbgr]

For the record before I forget (am on mobile right now), rusttype itself also broke the compatibility with their 0.7.2. Their only change from 0.7.1 is the update of their dependency ordered-float to 1.0, which does not compile on 1.24.1. Le 11 novembre 2018 21:53:00 GMT+01:00, Francesca Plebani <notifications@github.com> a écrit :

…

I agree with @Osspial that superficially making the CI pass isn't in the spirit of maintaining compatibility. I've created [an issue on `stb_truetype`](https://gitlab.redox-os.org/redox-os/stb_truetype-rs/issues/20) that will hopefully lead to an elegant resolution. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #698 (comment)

[francesca64]

At this point, I'm leaning towards just increasing the minimum required Rust version. It's been 6 months since we chose 1.24.1. Now Ubuntu 16.04 is up to 1.28.0, and 1.28.0 is just as old as 1.24.1 was when we picked it. It's still unclear to me how important it is to be conservative with the required version, but either way, staying further back increases maintenance costs.

[Osspial]

I'm okay with doing that. I'm not aware of many reasons for enforcing a minimum version besides making sure code works on commonly-available distributions of Rust. If commonly-available distributions support a newer version, I don't see the point in sticking with a version that requires a significant amount of work on our end to support.

[elinorbgr]

I also agree. I was on my side pondering the question of bumping the rust version in wayland-rs/sctk to improve the code with more recent rust features, but restrained myself to not break winit's guarantee.

[francesca64]

Should changing to 1.28.0 require a bump to 0.19.0? 0.18.0 already doesn't compile out of the box on 1.24.1, so it's sort of already an unlisted breaking change.

[elinorbgr]

Well, in that case it's just a matter of updating the readme and the travis build I'd say.