[OE-core] [OE-Core][master][PATCH] standard.py: Provide an additional option for devtool reset

Paul Eggleton paul.eggleton at linux.intel.com
Mon Mar 4 20:17:13 UTC 2019


On Friday, 8 February 2019 2:57:32 PM NZDT Sai Hari Chandana Kalluri wrote:
> The devtool reset command cleans the sysroot for a recipe in workspace.
> It also removes the append file but leaves the source code as in
> workspace. The source is not cleaned intentionally and the user has to
> manually remove it before calling devtool modify again.
> 
> Provide the user with an option to remove the source code from workspace
> by adding a flag to the devtool reset command. The --rm-source option for
> the devtool reset command will also clean the source code from the
> workspace along with the sysroot and the append file.
> Ex: devtool reset --rm-source zip or devtool reset -r zip

When I wrote this I made a conscious decision not to delete the source, in 
case the user has unsaved work in the source tree; at least then the user has 
to take an explicit step (an additional rm -rf) in order to delete it. You 
might argue that adding an option is the same as that explicit step, but I am 
still hesitant as you might for example pick a previously used command from 
your command history with -r in it and only realise after you've run it that 
you've just blown away a bunch of your work.

However, I have received the feedback from a number of people that they find 
it annoying that they have to delete the source themselves before being able 
to run devtool on the recipe again. I'd like to hear from the wider community 
on the following two questions:

1) Does the convenience of having this kind of option outweigh the potential 
danger of deleting unsaved work?

2) Are there issues that anyone is experiencing that force you to run devtool 
clean/finish and then re-run devtool modify (or add, or upgrade), making this 
kind of situation come up more frequently? Or is it mostly that the source 
directories end up being left around to stumble over some time later?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre




More information about the Openembedded-core mailing list