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 781016 - Provide a way for hard clean all related to a project (~/.cache/gnome-builder + %projectdir/.flatpak-builder + meson/autotools clean)
Provide a way for hard clean all related to a project (~/.cache/gnome-builder...
Status: RESOLVED OBSOLETE
Product: gnome-builder
Classification: Other
Component: general
3.23.x
Other Linux
: Normal normal
: ---
Assigned To: GNOME Builder Maintainers
GNOME Builder Maintainers
Depends on:
Blocks: 781010
 
 
Reported: 2017-04-07 08:55 UTC by Carlos Soriano
Modified: 2018-01-11 10:25 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Carlos Soriano 2017-04-07 08:55:53 UTC
I'm not sure if this is a fair or good addition, but let's consider it.

Given the current new integration of Flatpak and the fast evolving of Builder would be good to overcome some of the issues people find that are usually fixed by removing ~/.cache/gnome-builder + %projectdir/.flatpak-builder and doing a meson/autotools clean all.

So providing a UI or so for that would be good (although I'm regretting it while I write :D).

The alternative is just let them frustrate until they ask the question and we say to follow the steps described above manually.
Comment 1 Christian Hergert 2017-04-07 09:20:12 UTC
I'd like to understand how it got in that state before adding any workarounds.
Comment 2 Carlos Soriano 2017-04-07 21:49:42 UTC
fair enough, but we always had a "wipe and start over" for example in jhbuild for these situations. I'm honestly not sure we should have it in Builder, but I wonder if it would minimize frustration although we are very interested in fixing the underlying issues.
Comment 3 Matthew Leeds 2017-04-08 18:30:05 UTC
Implementing this would be a bit difficult given the lack of a recursive delete function in glib.
Comment 4 Christian Hergert 2017-04-08 18:55:51 UTC
We have IdeDirectoryReaper in libide/util that might be reusable.
Comment 5 Debarshi Ray 2017-04-12 14:52:42 UTC
(In reply to Matthew Leeds from comment #3)
> Implementing this would be a bit difficult given the lack of a recursive
> delete function in glib.

There is also https://git.gnome.org/browse/libglnx/tree/glnx-shutil.c#n80, but it is likely Linux-only.

(In reply to Christian Hergert from comment #4)
> We have IdeDirectoryReaper in libide/util that might be reusable.

I wonder if we can leverage the fact that ide_directory_reaper_add_glob isn't actually used, and wrap glnx_shutil_rm_rf_at on Linux. Probably not worth the trouble.
Comment 6 GNOME Infrastructure Team 2018-01-11 10:25:24 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-builder/issues/214.