[PATCH rtems_waf] rtems: Add uninstall option to the list of commands

[Chris Johns]

> On 5 May 2020, at 5:37 pm, Vijay Kumar Banerjee <vijay at rtems.org> wrote:
> 
> 
> 
> 
>> On Tue, May 5, 2020 at 9:56 AM Chris Johns <chrisj at rtems.org> wrote:
>> On 4/5/20 8:16 pm, Vijay Kumar Banerjee wrote:
>> > 
>> > 
>> > On Mon, May 4, 2020 at 4:39 AM Chris Johns <chrisj at rtems.org 
>> > <mailto:chrisj at rtems.org>> wrote:
>> > 
>> >     Hi
>> > 
>> >     Are uninstall command useful with RTEMS? A use case that shows how it
>> >     would be used may help.
>> > 
>> > The use case in mind was libbsd. The uninstall command comes handy in
>> > cleaning off the files that were installed, and there's no need to delete it
>> > manually. I remember having some issues with libbsd while taking a trial
>> > and error approach in searching for the right sources, the residue of the
>> > old build would often cause problems and I had to delete them manually.
>> 
>> I understand. I see this as a development issue and not something a user 
>> would typically do. A release can have the pieces in a vertically 
>> software stack built on top of each other, i.e. a single prefix. For 
>> development where you can have specific pieces that are moving relative 
>> to each other I recommend separate sandboxing. The user manual details 
>> this. Prefix based sandboxing lets you remove a specific prefix without 
>> needing to rebuild the whole stack.
>> 
>> >     I use separate prefixes to manage this. We do not track common files
>> >     when installing to a common prefix so building ARM and then PowerPC to
>> >     the same prefix then uninstalling only the PowerPC build would remove
>> >     files needed by ARM.
>> > 
>> > waf only removes the files that have been installed with install_files. If I
>> > run ./waf uninstall from libbsd, only the files under 
>> > arm-rtems5/beagleboneblack/lib
>> > are getting affected.
>> 
>> That must be the default uninstall for waf. We should decide to move one 
>> way or the other, that is remove the uninstall because it is broken or 
>> we fix it, i.e. your patch?
>> 
>> I hesitate adding something that is not manually tested often and so not 
>> kept up to date. Would a unit test be a solution? Something that 
>> collects a hash based stamp for all the files under a prefix, performs 
>> the install and the uninstall steps and then verifies the prefix tree is 
>> exactly the same?
>> 
> The uninstall function is currently broken but it would be nice to have.

Sure that is fine with me. 

> The unit-test approach sounds great and will make sure that it doesn't
> break anything. Is this an issue for the release if the uninstall is broken?

I suggest doing the patch for master and we can review it for 5.2.

> Is there any example of some unit-test added like this?

Not that I know of. If it is a single module maybe it can used in all our waf repos. 

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200505/55340188/attachment.html>