The build fails as the goocanvas isn't available anywhere for now. I would use a subproject and include goocanvas-3 in the source for now

@bilelmoussaoui should I release a goocanvas-3.0 for that?

No need for that, you can just use a wrap file with something like

subprojects/goocanvas.wrap

[wrap-git]
url = https://gitlab.gnome.org/GNOME/goocanvas.git
revision = goocanvas-3.0

and then include it in meson.build with

subproject('goocanvas')

@bilelmoussaoui feel free to rework the last commit if needed. If not I will try again later

This works if I manually compile and install goocanvas-3.0 on my system, but as expected, it doesn't work with a simple ninja build.

I pinged the folks at elementary to be sure the final release will be built with everything we're baking into the CI, in order to not release a busted version.

Meanwhile, I think we should implement the subproject as suggested by Bilal.
Meson subprojects seems to support also cmake, even if not entirely.

https://mesonbuild.com/Subprojects.html#toggling-between-system-libraries-and-embedded-sources
https://mesonbuild.com/CMake-module.html#cmake-subprojects

@albfan so, based on where elementary is going, transitioning to flatpak and all, I was wondering if we should wait.

We can decide to postpone the usage of goocanvas-3, alongside all the connected features, for when the transition to flatpak will be completed.
In this way, we can avoid overcomplicating our life, and simply relying on flatpak altogether.
What do you think?

We can leave this PR open and update it for when the flatpak day comes.

Sure, no hurry.

@albfan would you be able to update this PR so we can merge it since we're not targeting elementary OS 5 anymore and we're going full flatpak?

That sounds great, let me put everything else in place. Upstream work time!

upstream work on goocanvas is ready (at least for radii modifications)

https://mail.gnome.org/archives/ftp-release-list/2021-January/msg00074.html

Not sure about the timing for downstream distros to create goocanvas-3.0 development package.

Right now CI is modified to build goocanvas fro source.

@Alecaddd up to you to merge this.

If we are gonna focus on @flatpak development probably we want to migrate CI to be flatpak based. @bilelmoussaoui what do you think. (benefit: Speed, drawback: More apart from tradicional workflow, hard to provide support to tradicional developers)

upstream work on goocanvas is ready (at least for radii modifications)

https://mail.gnome.org/archives/ftp-release-list/2021-January/msg00074.html

Not sure about the timing for downstream distros to create goocanvas-3.0 development package.

Right now CI is modified to build goocanvas fro source.

@Alecaddd up to you to merge this.

If we are gonna focus on @flatpak development probably we want to migrate CI to be flatpak based. @bilelmoussaoui what do you think. (benefit: Speed, drawback: More apart from tradicional workflow, hard to provide support to tradicional developers)

The PR I sent & was merged already adds support for doing all what the current CI does in a flatpak sandboxed environment, so the current CI can be just removed if that's your question.

Also note that all the core elementary apps are using the same CI github action and it fairly safe to say it's working fine

Thanks @albfan for updating this and @bilelmoussaoui for giving the green light.
I'm waiting for the CI to complete the build and then I'll merge this.

I think we should consider creating a dedicated INSTALL.md file with the instructions on how to manually build and install goocnvas-3.0 in case the user's distro doesn't come with it.
But we can do that in a follow up PR.

Ah, I think it failed but the UI didn't update properly.

.github/workflows/build.yml#L20
You have an error in your yaml syntax on line 20

I added our custom vapi dir again for goocanvas-3.0.vapi

I open a new issue on vala about it, as it shows several differences with goocanvas-2.0.vapi.

https://gitlab.gnome.org/GNOME/vala/-/issues/1127

In case it takes longer than expected, we can cherry pick things from my generated file: https://gitlab.gnome.org/GNOME/vala/uploads/c25a743882ab89e4b96e0a8fb8257e8b/goocanvas-3.0.vapi

Strangely, this fails for the flatpak CI reporting Error: Build failed: Error: The process '/usr/bin/xvfb-run' failed with exit code 1
@bilelmoussaoui, any clue on this?

I'm also considering removing the xvfb and the whole automated test run in the CI, which is also disabled right now, since the GitHub CI is not powerful enough to handle GUI tests.

Locally this works, so I'm good with merging this and then fixing the Flatpak CI later.
What do you guys think?

Strangely, this fails for the flatpak CI reporting Error: Build failed: Error: The process '/usr/bin/xvfb-run' failed with exit code 1
@bilelmoussaoui, any clue on this?

I'm also considering removing the xvfb and the whole automated test run in the CI, which is also disabled right now, since the GitHub CI is not powerful enough to handle GUI tests.

The flatpak manifest has to be updated as well, if you look few lines before that error you will see it fails to apply a patch that's already part of the new 3.0 release

The flatpak manifest has to be updated as well, if you look few lines before that error you will see it fails to apply a patch that's already part of the new 3.0 release

Do you want to suggest the edit in this PR, or it's okay if we merge and then you create a follow up PR to fix the issue?

The flatpak manifest has to be updated as well, if you look few lines before that error you will see it fails to apply a patch that's already part of the new 3.0 release

Do you want to suggest the edit in this PR, or it's okay if we merge and then you create a follow up PR to fix the issue?

My latest two commits should hopefully fix it, I will keep an eye on it till it finishes ^^

Looks all green now :D