11406 2017-04-24 22:39:55 +0000 Add --dist-clean, --force, or some other flag to 'devtool reset' to clean all recipe cruft 2025-02-14 16:48:18 +0000 1 1 7 Build System, Metadata & Runtime OE-Core devtools / tool chain 2.4 x86 Multiple NEW . Medium enhancement 5.99 1 brianx.j.kurle unassigned meta.mr.watcher meta.watcher randy.macleod sgw --- --- Yes (doc changes required) oldest_to_newest 72803 0 brianx.j.kurle 2017-04-24 22:39:55 +0000 While working with creation of reproducible steps via devtool within an installed eSDK, an additional flag would be desired that would force a cleaning of all the cruft generated (e.g., sources/<recipe>*, attic/<recipe>*, downloads/<recipe>*, tmp/work/*/<recipe>*, and any other places droppings related to the recipe). devtool reset <recipe> in this scenerio is usually followed by several other steps to restore a prestine environment (i.e., before the devtool add <recipe> was performed), and this is tedious and error prone. 72847 1 bluelightning 2017-04-25 20:53:33 +0000 I'd avoided adding an option like this particularly with regard to the source tree for fear of users getting in the habit of using it every time until that one day when they forget to save their work within the source tree, and then devtool complies and trashes it. Then again, they could just as easily rm -rf it as instructed and end up in the same situation. However, even if we do go ahead and add it, I would like to try to avoid users needing to use this option as much as possible by fixing any issues caused by cruft hanging around. Other than the annoyance of sources/<recipe> triggering an error when repeating the same devtool add, any warnings you get about files in the attic, and bug 11407, are there any other issues you have hit because of files being left around that this option would clear out? 72848 2 brianx.j.kurle 2017-04-25 22:05:17 +0000 I've occasionally encountered inexplicable build errors and reconfiguration problems. Generally it is from getting a recipe or command incorrect (e.g., wrong URL), attempting to reset the recipe in the workspace and redoing it. The desire is to make the environment pristine for just the recipe desired (or all if -a) without blowing away the entire eSDK (or chasing all the caches to selectively remove), reinstall and rebuild. If it was only a couple locations to remove, I'd have been fine. As I started writing a script to clean the caches and various other locations, I thought it be better if it was included in devtool, itself. Use cases: Working through steps to refine a demo example workflow for a team. Similarly, reworking steps (and correcting errors in steps) for documentation on examples relevant to a team project. (both variants being where I've encountered these problems). The very nicety of the cache can come back to haunt you when you don't expect it (e.g., wrong URL, but same filename in URL). I appreciate not wanting users to shoot themselves in the foot, but there are uses for the -f (even with rm, cp, mv, ln, et al.) The parameter shouldn't be a normal use case (as -f in most cases isn't normal), but one for the exceptional cases. I would argue that requiring the user to explicitly state they wish to shoot their foot off is acceptable as you can point back to the command issued and state you accepted the terms and consequences thereof. 93587 3 randy.macleod 2022-06-23 15:12:19 +0000 We many not want fix this one for the reasons Paul mentioned in comment 1. We have to be careful with user data! 96929 4 randy.macleod 2023-10-24 14:24:45 +0000 Bulk move from 4.99 or 0.00 to 5.99 101002 5 randy.macleod 2025-02-14 16:46:33 +0000 bulk change to add Saul's non-WR address. 101050 6 randy.macleod 2025-02-14 16:48:18 +0000 Bulk change: Remove Saul's old WR address.