There are times when I would like to wipe out all my build products but keep the source downloads. I would do this with the command line with removing the tmp directory. I can't figure out how to do it in hob. So there should be a trashcan option of some kind. And while we're at it, can we have a way to delete targets to trigger rebuilding the image and kernel? Or is that asking for too much?
Add options to clean the tmp in Hob.
This needs some design. To be honest, I am not sure if I'll have time within 1.3. Cheers Belen
Move to 1.4 per Belen's request
I will put this bug in need info, because it needs a design. Thanks!
It looks like this is 2 different bugs: Bug 1: I want to remove the /tmp directory Bug 2: I want to delete targets to trigger rebuilding the image and kernel Bug 1: This is relatively straightforward. We could add a button to the "Images" dialog with label "Delete all build output". When you click that button, we delete the tmp directory. The question is: how do we do it? 2 options here: Option 1: do it in the background, which basically means I will be able to start a new build while the /tmp directory is being removed. From an UI point of view, this would require adding a status bar to the Hob primary window to report progress (info on status bars here: https://developer.gnome.org/hig-book/3.5/controls-status-bars.html.en), or using a non-modal progress window (https://developer.gnome.org/hig-book/3.5/windows-progress.html.en). Option 2: do it as a modal process, which means you cannot interact with Hob until the /tmp directory has been removed. Which option we implement depends on how long it takes to remove the /tmp directory and engineering effort required. Bug 2: I am not sure what the use case is here. Is this about creating an interface to the clean command, so that I can remove everything related to a specific target and do a clean build for that target? If that's the case, we might have a problem here. The logical way of doing this would be adding a 'rebuild from scratch' option for targets. This could be done on the information windows we have for recipes, for example, or via option menus (right click > rebuild from scratch), although using option menus would force us to add a menu bar to Hob, since option menus must never be the only way of accessing a piece of functionality in a desktop application. The problem is: Hob displays recipes, not targets. So Hob will show 'quilt' but not 'quilt-native'. If what you want to clean is quilt-native, well: you can't. That's why I think bug 2 is not going to happen: we could tackle bug 1. Let me know what you think. In the meantime, I'll set the status of the bug to 'need info'.
(In reply to comment #5) > It looks like this is 2 different bugs: > > Bug 1: I want to remove the /tmp directory > Bug 2: I want to delete targets to trigger rebuilding the image and kernel > > Bug 1: > > This is relatively straightforward. We could add a button to the "Images" > dialog with label "Delete all build output". When you click that button, we > delete the tmp directory. The question is: how do we do it? 2 options here: > > Option 1: do it in the background, which basically means I will be able to > start a new build while the /tmp directory is being removed. From an UI > point of view, this would require adding a status bar to the Hob primary > window to report progress (info on status bars here: > https://developer.gnome.org/hig-book/3.5/controls-status-bars.html.en), or > using a non-modal progress window > (https://developer.gnome.org/hig-book/3.5/windows-progress.html.en). > > Option 2: do it as a modal process, which means you cannot interact with Hob > until the /tmp directory has been removed. > > Which option we implement depends on how long it takes to remove the /tmp > directory and engineering effort required. We can cheat. We can rename the directory to something out the way, then delete it in a backgrounded process so the user can continue to interact with the system. > Bug 2: > > I am not sure what the use case is here. Is this about creating an interface > to the clean command, so that I can remove everything related to a specific > target and do a clean build for that target? If that's the case, we might > have a problem here. > > The logical way of doing this would be adding a 'rebuild from scratch' > option for targets. This could be done on the information windows we have > for recipes, for example, or via option menus (right click > rebuild from > scratch), although using option menus would force us to add a menu bar to > Hob, since option menus must never be the only way of accessing a piece of > functionality in a desktop application. > > The problem is: Hob displays recipes, not targets. So Hob will show 'quilt' > but not 'quilt-native'. If what you want to clean is quilt-native, well: you > can't. > > That's why I think bug 2 is not going to happen: we could tackle bug 1. Let > me know what you think. In the meantime, I'll set the status of the bug to > 'need info'. This second issue is an interesting one. At least in theory, you should never need to clean and rebuild something. If there are changes, bitbake will detect them, the sstate/task checksum will change and it will rebuild. Only if the user is hacking things outside hob will this become an issue and if they're doing that, they can probably arrange for it to rebuild anyway. So I'd say this is a lesser priority.
(In reply to comment #6) > (In reply to comment #5) > > It looks like this is 2 different bugs: > > > > Bug 1: I want to remove the /tmp directory > > Bug 2: I want to delete targets to trigger rebuilding the image and kernel > > > > Bug 1: > > > > This is relatively straightforward. We could add a button to the "Images" > > dialog with label "Delete all build output". When you click that button, we > > delete the tmp directory. The question is: how do we do it? 2 options here: > > > > Option 1: do it in the background, which basically means I will be able to > > start a new build while the /tmp directory is being removed. From an UI > > point of view, this would require adding a status bar to the Hob primary > > window to report progress (info on status bars here: > > https://developer.gnome.org/hig-book/3.5/controls-status-bars.html.en), or > > using a non-modal progress window > > (https://developer.gnome.org/hig-book/3.5/windows-progress.html.en). > > > > Option 2: do it as a modal process, which means you cannot interact with Hob > > until the /tmp directory has been removed. > > > > Which option we implement depends on how long it takes to remove the /tmp > > directory and engineering effort required. > > We can cheat. We can rename the directory to something out the way, then > delete it in a backgrounded process so the user can continue to interact > with the system. Cristiana: I suspect this will be assigned to you, so what do you think about RP's suggestion? Also, do you have any thoughts on the UI widget to use (status bar or progress window)? > > > > Bug 2: > > > > I am not sure what the use case is here. Is this about creating an interface > > to the clean command, so that I can remove everything related to a specific > > target and do a clean build for that target? If that's the case, we might > > have a problem here. > > > > The logical way of doing this would be adding a 'rebuild from scratch' > > option for targets. This could be done on the information windows we have > > for recipes, for example, or via option menus (right click > rebuild from > > scratch), although using option menus would force us to add a menu bar to > > Hob, since option menus must never be the only way of accessing a piece of > > functionality in a desktop application. > > > > The problem is: Hob displays recipes, not targets. So Hob will show 'quilt' > > but not 'quilt-native'. If what you want to clean is quilt-native, well: you > > can't. > > > > That's why I think bug 2 is not going to happen: we could tackle bug 1. Let > > me know what you think. In the meantime, I'll set the status of the bug to > > 'need info'. > > This second issue is an interesting one. At least in theory, you should > never need to clean and rebuild something. If there are changes, bitbake > will detect them, the sstate/task checksum will change and it will rebuild. > Only if the user is hacking things outside hob will this become an issue and > if they're doing that, they can probably arrange for it to rebuild anyway. > So I'd say this is a lesser priority. So it looks like we agree about not doing this.
Hi Belen, Regarding the estimation, 4 days seems ok. It depends on the design(how complicated it is), because what it is behind isn't hard to implement. I think that a status bar would be ok, but I don't understand where it will be placed. Thanks, Cristiana
(In reply to comment #8) > Hi Belen, > > Regarding the estimation, 4 days seems ok. It depends on the design(how > complicated it is), because what it is behind isn't hard to implement. > I think that a status bar would be ok, but I don't understand where it will > be placed. > Thanks, > Cristiana Thanks! I'll be working on the design in the next few days. We can then adjust estimate as needed.
We're no longer going to add this feature to HOB.
Boo