After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 782426 - Use breadth-first for flatpak manifest discover
Use breadth-first for flatpak manifest discover
Status: RESOLVED FIXED
Product: gnome-builder
Classification: Other
Component: general
Flatpak Stable Channel
Other Linux
: Normal normal
: ---
Assigned To: GNOME Builder Maintainers
GNOME Builder Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-05-10 10:36 UTC by Carlos Soriano
Modified: 2017-07-07 21:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Use breadth-first in flatpak discovery (3.66 KB, patch)
2017-07-01 17:18 UTC, Günther Wutz
none Details | Review
overworked patch for breadth-first (3.66 KB, patch)
2017-07-05 21:34 UTC, Günther Wutz
none Details | Review
correct overworked patch for breadth-first (6.00 KB, patch)
2017-07-06 19:26 UTC, Günther Wutz
committed Details | Review

Description Carlos Soriano 2017-05-10 10:36:51 UTC
Currently Builder uses deep-first, that makes manifest deep in the hierarchy being pick up first rather than manifest in the root folder.

It would be ideal to have a breadth-first enumeration, so manifes closer to the root are pickp up first.

Of course the ideal solution for handling manifest would be different, but it's a nice touch that we can fix soon.

Relevant code is in https://git.gnome.org/browse/gnome-builder/tree/plugins/flatpak/gbp-flatpak-configuration-provider.c#n786
Comment 1 Carlos Soriano 2017-05-10 10:39:48 UTC
Task for newcomers, it's a nice one to get started with Builder contribution.
Comment 2 Christian Hergert 2017-05-10 18:46:19 UTC
The GbpFlatpakBuildSystemDiscover already does this, so that code can probably be copied into the configuration provider.

https://git.gnome.org/browse/gnome-builder/tree/plugins/flatpak/gbp-flatpak-build-system-discovery.c#n38
Comment 3 Günther Wutz 2017-07-01 17:18:36 UTC
Created attachment 354774 [details] [review]
Use breadth-first in flatpak discovery

My first contribution. I changed the behaviour to breadth-first. The code is similiar to that of build-system-discovery so maybe we should refactor this out in a utility function.
Comment 4 Christian Hergert 2017-07-01 20:26:03 UTC
Review of attachment 354774 [details] [review]:

Nice working putting your first GNOME Builder patch together! Couple quick things to address and then we can merge.

::: plugins/flatpak/gbp-flatpak-configuration-provider.c
@@ -867,3 +871,5 @@
-          else if (!gbp_flatpak_configuration_provider_find_manifests (self, file, configs, cancellable, error))
-            return FALSE;
-          continue;
+
+          if (depth < DISCOVERY_MAX_DEPTH - 1)
+            {
... 2 more ...

Only 2 spaces for indentation here.

@@ +926,3 @@
+            return FALSE;
+
+          return gbp_flatpak_configuration_provider_find_manifests (self, file, configs, depth + 1, cancellable, error);

You probably don't want to unconditionally return from the first child directory check. So probably something to the tune of:

  if (find_manifests(...))
    return TRUE;
Comment 5 Christian Hergert 2017-07-01 20:27:55 UTC
Review of attachment 354774 [details] [review]:

::: plugins/flatpak/gbp-flatpak-configuration-provider.c
@@ +926,3 @@
+            return FALSE;
+
+          return gbp_flatpak_configuration_provider_find_manifests (self, file, configs, depth + 1, cancellable, error);

Or rather, if (!find_manifests(...)) since that is the error case. Although, you might just want to ignore errors altogether from the child directories.
Comment 6 Günther Wutz 2017-07-02 09:18:22 UTC
Wouldn't it be easier to check in gbp_flatpak_configuration_provider_load_worker for an empty error instead to rely on the return boolean? So we would catch an error in every case and we could change it to an void function.
Comment 7 Christian Hergert 2017-07-03 06:52:02 UTC
Switching various functions to void and keeping the GError in the local scope seems reasonable to me.
Comment 8 Günther Wutz 2017-07-05 21:34:43 UTC
Created attachment 354970 [details] [review]
overworked patch for breadth-first

Changed it according to Comment #6. I check now for error != null instead to check for boolean values. The only thing which i am not sure is when we cancelled. Should we check this state independently? (i think error is null even if it got cancelled - so this state wasn't checked before this change)
Comment 9 Christian Hergert 2017-07-05 22:54:07 UTC
Review of attachment 354970 [details] [review]:

Hrmm, it looks like maybe some things are missing from this patch based on the comment?
Comment 10 Günther Wutz 2017-07-06 19:26:32 UTC
Created attachment 355043 [details] [review]
correct overworked patch for breadth-first

Sorry this should be now the correct patch - i somehow mixed the patchfiles up
Comment 11 Christian Hergert 2017-07-07 21:55:05 UTC
Well done! Thanks!

I've also added a followup commit to add you to AUTHORS and our about dialog
credits.