<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"><br></div><div dir="ltr"><blockquote type="cite">On 5 May 2020, at 5:37 pm, Vijay Kumar Banerjee <vijay@rtems.org> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 5, 2020 at 9:56 AM Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 4/5/20 8:16 pm, Vijay Kumar Banerjee wrote:<br>
> <br>
> <br>
> On Mon, May 4, 2020 at 4:39 AM Chris Johns <<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a> <br>
> <mailto:<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>>> wrote:<br>
> <br>
> Hi<br>
> <br>
> Are uninstall command useful with RTEMS? A use case that shows how it<br>
> would be used may help.<br>
> <br>
> The use case in mind was libbsd. The uninstall command comes handy in<br>
> cleaning off the files that were installed, and there's no need to delete it<br>
> manually. I remember having some issues with libbsd while taking a trial<br>
> and error approach in searching for the right sources, the residue of the<br>
> old build would often cause problems and I had to delete them manually.<br>
<br>
I understand. I see this as a development issue and not something a user <br>
would typically do. A release can have the pieces in a vertically <br>
software stack built on top of each other, i.e. a single prefix. For <br>
development where you can have specific pieces that are moving relative <br>
to each other I recommend separate sandboxing. The user manual details <br>
this. Prefix based sandboxing lets you remove a specific prefix without <br>
needing to rebuild the whole stack.<br>
<br>
> I use separate prefixes to manage this. We do not track common files<br>
> when installing to a common prefix so building ARM and then PowerPC to<br>
> the same prefix then uninstalling only the PowerPC build would remove<br>
> files needed by ARM.<br>
> <br>
> waf only removes the files that have been installed with install_files. If I<br>
> run ./waf uninstall from libbsd, only the files under <br>
> arm-rtems5/beagleboneblack/lib<br>
> are getting affected.<br>
<br>
That must be the default uninstall for waf. We should decide to move one <br>
way or the other, that is remove the uninstall because it is broken or <br>
we fix it, i.e. your patch?<br>
<br>
I hesitate adding something that is not manually tested often and so not <br>
kept up to date. Would a unit test be a solution? Something that <br>
collects a hash based stamp for all the files under a prefix, performs <br>
the install and the uninstall steps and then verifies the prefix tree is <br>
exactly the same?<br>
<br></blockquote><div>The uninstall function is currently broken but it would be nice to have.</div></div></div></div></blockquote><div><br></div>Sure that is fine with me. <div><br><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>The unit-test approach sounds great and will make sure that it doesn't</div><div>break anything. Is this an issue for the release if the uninstall is broken?</div></div></div></div></blockquote><div><br></div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">I suggest doing the patch for master and we can review it for 5.2.</span><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>Is there any example of some unit-test added like this?</div></div></div></div></blockquote><div><br></div>Not that I know of. If it is a single module maybe it can used in all our waf repos. <br><div><br></div><div>Chris</div></div></body></html>