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

[Vijay Kumar Banerjee]

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.
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?
Is there any example of some unit-test added like this?

Thanks,
Vijay

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