winit suddenly requires `cmake` dependency
Jasper-Bekkers opened this issue · 28 comments
It looks like ever since sctk-adwaita got upgraded (and their dependencies got upgraded) this crate is dragging in cmake, polluting everybody's build system and setup. Our project has a zero-tolerance policy for cmake (or other build time tools since we just want to be able to build trough cargo with no additional tools required to be set up).
Dependency tree seems to be:
sctk-adwaita ->crossfont -> servo-fontconfig -> servo-fontconfig-sys -> expat-sys -> cmake
Presumably all of this isn't strictly required and can be disabled?
Presumably all of this isn't strictly required and can be disabled?
Just disable sctk-adwaita feature? Or install system headers for fontconfig, freetype?
Just disable sctk-adwaita feature? Or install system headers for fontconfig, freetype?
Honestly if sctk-adwaita drags in such major dependencies, I don't think it should be enabled by default
The point to have decorations that make sense on Wayland. Like you know, that you will have a text in your title bar. That's the main point to provide sensible defaults. Otherwise you'll be surprised that your window suddently doesn't have a title bar or actual buttons.
If anything we can abort compilation if you don't have system library headers installed.
I don't think any of that is needed, sensible titlebars are very welcome, however, that can all be achieved without reliance on cmake (and by having a sensible build setup).
Well, bring it to whoever builds those system crates and requires to put the entire thing just to build it just in case?
I'll alter to just abort. So you won't have a cmake problem.
On alternative might be to swap out servo-fontconfig with fontconfig/yeslogic-fontconfig, which doesn't fall back to vendoring fontconfig and expat when it can't find a compatible version of fontconfig at build time, but that's a decision to make for whoever is maintaining crossfont.
On alternative might be to swap out servo-fontconfig with fontconfig/yeslogic-fontconfig, which doesn't fall back to vendoring fontconfig and expat when it can't find a compatible version of fontconfig at build time, but that's a decision to make for whoever is maintaining crossfont.
Servo does the same thing. That's the point. The issue is that it fallbacks. We have a flag in crossfont to not ever fallback here, which is what they want. I've patched sctk-adwaita to use that flag instead, but it'll have time for it to release.
whoever is maintaining crossfont.
It's alacritty's project, so it's kind of me.
Reopening since we want to force system libraries.
It seems to still pull in cmake:
$ cargo tree -i cmake
cmake v0.1.48
[build-dependencies]
├── expat-sys v2.1.6
│ └── servo-fontconfig-sys v5.1.0
│ └── servo-fontconfig v0.5.1
│ └── crossfont v0.5.0
│ └── sctk-adwaita v0.4.1
│ └── winit v0.26.1 (https://github.com/rust-windowing/winit?rev=f09259f6#f09259f6)
│ ...
└── freetype-sys v0.13.1
├── freetype-rs v0.26.0
│ └── crossfont v0.5.0 (*)
└── servo-fontconfig-sys v5.1.0 (*)At the same time the requirement for pkg-config makes me unable to cross-compile winit for an aarch64 platform where I don't have pkg-config support (yet, could be added but it's a hassle), nor Android it seems.
Fortunately we can circumvent both issues by disabling Client-Side Decorations, as we don't render any of those.
I'm pretty sure you can use env variable for pkg-config to cross it. I've been doing so for a long time in alacritty.
You're cross compiling for linux, not android, right? Since none of that should be triggered for android target.
If @maroider thinks that we shouldn't have any fancy decorations on Wayland by default, then we can swap defaults.
I feel like the default should be what works best for the most amount of people, and that seems to me like it would require the fancy decorations.
You're cross compiling for linux, not android, right? Since none of that should be triggered for android target.
Correct, aarch64-unknown-linux-gnu. I don't remember what I was doing when writing "nor Android it seems" yesterday, because it is definitely compiling just fine.
I'm pretty sure you can use env variable for pkg-config to cross it.
Allowing it is easy, but I'll have to pull the .pc files and libraries from the target machine to make it link. Not the end of the world, but a hassle nonetheless.
Regarding decorations, I wanted to ask if these ugly non-GNOME borders are also caused - and fixed - by this feature on wayland?:
That'd be an incentive for me to set that up. I've only used this application on Sway thus far without any window borders and didn't notice.
In order to rule out any issues in my application I tried the winit examples. But none actually show a window on neither my x64+sway desktop nor aarch64+GNOME "phone" (both on Wayland)? Not even when going back to v0.26.1. @kchibisov are the examples missing any kind of event handling or Window setup to make it work properly?
@MarijnS95 winit examples are not showing anything on Wayland unfortunatelly, since you should draw on Wayland to make your window visible, but none of the examples are drawing anything. It's recommended to use glutin examples here. (or add something like softbuffer right into winit examples, that's why I've suggested it, but it's clear now that softbuffer isn't a good project in terms of quality, so we should add something our selves).
Regarding decorations, I wanted to ask if these ugly non-GNOME borders are also caused - and fixed - by this feature on wayland?:
Yes, the goal is to provide more visually pleasant decorations. That's how they look.
They also have a light variant(you can control that when building a window in winit or by using environment variable).
The decorations on GNOME will always be non-native, since winit isn't using gtk and won't do so. But drawing something similar looking or at least with text is preferred imho, like we do now.
@kchibisov Thanks for explaining, you mentioned softbuffer before so it'd be good to have some solution to make the examples run on Wayland again.
Indeed, after setting up cross-compilation for these libs through pkg-config the window borders are more pleasant again.
I just expected the window manager and compositor to take care of and be able to render them natively (if the application doesn't request custom rendering). Guess I have more to learn about them - or specifically Wayland?
However, back to the original issue: cmake is still in the dependency graph, despite stating in #2381:
This should force the use of system libraries for Fontconfig
and freetype instead of building them with cmake if missing.
I just expected the window manager and compositor to take care of and be able to render them natively (if the application doesn't request custom rendering). Guess I have more to learn about them - or specifically Wayland?
GNOME refuses to support server-side decorations. So we must draw something ourselves.
However, back to the original issue: cmake is still in the dependency graph, despite stating in #2381:
IIRC it's still there, but not used anymore. Is it causing issues?
It seems like expat-sys is still trying to invoke it...
EDIT: And it'll a problem generally in the sense of dragging in unneeded dependencies, and not making it through cargo-deny if we were to deny this dependency (which we do on a mental basis, but were planning to configure that way).
Hm, That's unfortunate.
https://github.com/servo/libfontconfig/blob/master/Cargo.toml Looks like this is where the force_system_lib feature isn't propagated into expat-sys nor freetype-sys, only fontconfig's pkg-config error is non-fatal based on that.
Freetype won't build with cmake, look at its build.rs. However expat I think can. The original flag was added to mitigate fontconfig from building.
Freetype won't build with cmake, look at its build.rs.
It still pulls in this dependency into the tree even if unlikely to be ran thanks to the env var; it should just be guarded by a feature toggle as well or instead.
The point to have decorations that make sense on Wayland. Like you know, that you will have a text in your title bar. That's the main point to provide sensible defaults. Otherwise you'll be surprised that your window suddently doesn't have a title bar or actual buttons.
Why does winit need to support degenerate display managers without server-side decorations? Do those exist on real desktop systems?
EDIT: sorry, after reading the thread in its entirety I got my answer.
GNOME refuses to support server-side decorations. So we must draw something ourselves.
Ignore...
@kchibisov I think both crates can be reworked to make cmake optional, but we can't base it on force_system_lib since that'd require an inversion in Cargo.toml which I don't think is possible (enable the optional cmake crate when force_system_lib is not set).
Instead we might have to have a cmake feature, and replace force_system_lib with enable_cmake or something similar in libfontconfig.
Thoughts?
Yeah this was a bit of a pain building my game in ubuntu:16.04 (to maintain compat) where cmake is too old to work with freetype-sys. Working around that, by dling newer cmake, I faced bundling additional libs with my game to solve linking failures across the distros I support (libfontconfig.so.1, libfreetype.so.6, libpng12.so.0, libexpat.so.1).
I think I can make that work, but it's fairly high effort to render a 2 word wayland title. In the end I went with the wayland-csd-adwaita-notitle feature. It would be nice to have a rust-text alternative to freetype option for wayland titles, perhaps that can be added to sctk-adwaita?
Although this was already mentioned here, I'll say it anyway:
If you want to eliminate the system dependency, just use wayland-csd-adwaita-notitle there is no reason to remove all of the decorations. Rendering decorations is done in pure rust, so you can still keep the "fancy" decorations, and just drop the title.
To quote the changelog:
wayland-csd-adwaitafeature that enables proper CSD with title rendering using FreeType system library.wayland-csd-adwaita-notitlefeature that enables CSD but without title rendering.
That being said, Alex's ab_glyph version of title rendering got merged in sctk-adwaita already, and I will release it shortly, so winit could expose this option as well, but that's not for me to decide.
but it's clear now that softbuffer isn't a good project in terms of quality, so we should add something our selves
Hi, softbuffer developer here. Would you be willing to share what your issues with it are? I had some issues relating to my employment contract with a new employer that made FOSS contributions a bad idea so I had to let some issues & PRs sit, but the contract issues are resolved now so I'm starting to process the backlog.
@john01dav I'd suggest to contact @i509VCB on that regard wrt Wayland.
Wrt X11 we had issues here #2246.