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

[Vijay Kumar Banerjee]

On Tue, May 5, 2020 at 4:13 PM Chris Johns <chrisj at rtems.org> wrote:
>
>
> 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.
>

Hi Chris,

I added support in rtems_waf to test the uninstall function, following
the approach that you suggested. I'm attaching the patch here, please
have a look.

I am using it in libbsd by calling it from wscript like this:
```
diff --git a/wscript b/wscript
index 0979644a..74fc1f48 100644
--- a/wscript
+++ b/wscript
@@ -226,6 +226,9 @@ def configure(conf):
     update_builders(conf, conf.env.BUILDSET)
     rtems.configure(conf, bsp_configure)

+def test(bld):
+    rtems.test_uninstall(bld)
+
 def build(bld):
     rtems.build(bld)
     builders[bld.libbsd_buildset_name].build(bld)
```
If this approach looks alright to you, I'll send a v2 of the patchset
for libbsd and rtems_waf for review.

Thanks,
Vijay
>
> Chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-rtems-Add-function-to-test-waf-uninstall.patch
Type: text/x-patch
Size: 1782 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200508/f04af2c6/attachment.bin>