On 4/5/20 8:16 pm, Vijay Kumar Banerjee wrote:
On Mon, May 4, 2020 at 4:39 AM Chris Johns <chr...@rtems.org
<mailto:chr...@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?
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
