Conversation
Signed-off-by: Aaron Erhardt <aaron.erhardt@t-online.de>
|
I am failing a bit to see why we would run this on pull requests |
|
It's true, it's very unlikely that the Rust code fails only on Windows so using it for pull requests isn't that useful. The idea was to find regressions for the windows installation quickly so a scheduled run every day or something like this would be an option, too. |
There were changes I did in the past that broke windows builds :-) |
|
Okay :) |
| - name: Prepare GTK build | ||
| run: | | ||
| cd /gtk | ||
| meson setup builddir --prefix=C:/gnome -Dbuild-tests=false -Dmedia-gstreamer=disabled |
There was a problem hiding this comment.
Should also disable building the examples/demo
| meson setup builddir --prefix=C:/gnome -Dbuild-tests=false -Dmedia-gstreamer=disabled | |
| meson setup builddir --prefix=C:/gnome -Dbuild-tests=false -Dbuild-examples -Ddemos=false -Dmedia-gstreamer=disabled |
|
Not a blocker, but what would be needed to setup the caching? also we might want to build the examples / run the tests on windows as well |
| uses: actions-rs/cargo@v1 | ||
| with: | ||
| command: build | ||
| args: --manifest-path gtk4/Cargo.toml |
There was a problem hiding this comment.
| args: --manifest-path gtk4/Cargo.toml | |
| args: --workspace |
After #698 has been merged and you've rebased this branch, I would expect this to work fine.
|
I've updated the build command (on my testing branch) to More interestingly however, this caused the installation to fail: https://github.com/AaronErhardt/gtk4-rs/runs/4175328969?check_suite_focus=true |
|
@AaronErhardt Maybe cache |
|
@Hofer-Julian I'm not caching yet because the build from scratch already fails. I'm wondering whether this should be reported upstream... |
Sounds good. |
| - name: Clone GTK | ||
| run: | | ||
| cd / | ||
| git clone https://gitlab.gnome.org/GNOME/gtk.git --depth 1 |
There was a problem hiding this comment.
should this use tagged version instead of HEAD?
There was a problem hiding this comment.
As I pointed out earlier this workflow was mainly designed to find regressions in the windows installation instructions. Therefore I think using the latest version is fine and more convenient unless we can update the tag name automatically. Also this would allow us to more quickly find problems with the upstream code I think.
Or is there a good reason to use a tagged version?
There was a problem hiding this comment.
Finding regressions sounds good. Let's hope that this build doesn't break too often otherwise it might become annoying.
What I am personally more interested though is testing gtk4-rs om Windows. Here we will want to use the same tagged gtk version that we use in the docker image
There was a problem hiding this comment.
If we get caching working it should be fine to build gtk in two different workflows.
Definitely, it should use the same version as the one used in the docker image; which is 4.5.0 for now :-) |
Can you try with different variants of the options to see which ends up causing the issue? |
I will continue my work on this next week. I'll be pretty busy over the next few days. |
|
@AaronErhardt what is the status of this one? if you don't plan to work on it anytime soon, i can push the changes on top of it and get a working windows CI. |
I tracked down the issue to building gtk with Closing this one in favour of #798 |
5 participants
This took me embarrassingly long to get it working...
At this point, it just compiles the gtk4 crate from this repository with the windows-msvc toolchain. Maybe tests could be added and also a cache to speed up compilation because compiling GTK from source takes roughly 15 minutes.