[Enhancement Request] Library Remove Support

[CohenSteed]

For toolflow/automation development, it is common, if not easy, to mess up the linkage between a fusesoc library designation and the necessary files.

Please add the ability for fusesoc to REMOVE a library. Two thoughts: 1 - standard software practice: if you have an Add command, it implies there is a Remove/Delete/Revert command. This doesn't not currently exist, and the manual process is not straightforward or documented. 2 - Spec for how the removal may want to work:

• Update the fusesoc.conf file specified in the command. If none is specified, update the default one (~/.config/fusesoc/fusesoc.conf).
• If the requested library deletion does not exist inside the configuration file, continue to check the cache, config, and local spaces to clear out the relevant linkage and libraries. This serves as a re-sync in addition to removal.

The intent is to allow CAD to explore how to link this tool into other flows without having to do a heavy-handed 'rm -rf' every time a new library linkage is tested.

[olofk]

I can only agree. FTR I think it would make sense to have two variants One that removes the library and one that just removes the reference from the fusesoc.conf file.

* Update the fusesoc.conf file specified in the command. If none is specified, update the default one (~/.config/fusesoc/fusesoc.conf).

I would like to change this slightly. If no file is specicifed, first check fusesoc.conf in current dir, then check if it's in the user-global (~/.config/fusesoc/fusesoc.conf)

* If the requested library deletion does not exist inside the configuration file, _continue to check the cache, config, and local spaces to clear out the relevant linkage and libraries_. This serves as a re-sync in addition to removal.

Not sure I get what you mean here. Do you want to remove libraries that are not specified in any fusesoc.conf file? That's not possible since a library can be pretty much anywhere. But perhaps I misunderstood

Anyway, great to have this issue raised. Let's finalize the spec

[CohenSteed]

I would like to change this slightly. If no file is specicifed, first check fusesoc.conf in current dir, then check if it's in the user-global (~/.config/fusesoc/fusesoc.conf)

Absolutely. This is the natural priority hierarchy. I'm on board.

* If the requested library deletion does not exist inside the configuration file, _continue to check the cache, config, and local spaces to clear out the relevant linkage and libraries_. This serves as a re-sync in addition to removal.

Not sure I get what you mean here. Do you want to remove libraries that are not specified in any fusesoc.conf file? That's not possible since a library can be pretty much anywhere. But perhaps I misunderstood

There's an implied problem where files left over in these spaces may be used by references inside the libraries. Honestly, the notion is how to clean up any space populated by the tool.

Let's make sure we're talking about the same spaces, since I may have some errors here. There are three locations where files are put by fusesoc when executing:

• ~/.cache/fusesoc
• ~/.local/share/fusesoc
• ~/.config/fusesoc/fusesoc.conf

The goal is to be able to clean these up, including the ability to coherently remove a library from the fusesoc.conf and also remove associated items from ~/.cache and/or ~/.local/share

My comment is intended to say - if a library is passed in to be removed from the .conf file (any .conf file), go ahead and check the "local files" associated with that library in ~/.local/share/fusesoc and remove them, too. This could be a separate command from "remove from the .conf file" - but it would be a clean way to make sure the library is absolutely removed from the "default" location. User-customized locations should not be removed. Example: I have local RTL, and some published, open RTL. The .core file I'm using specifies my local stuff and makes a reference to externally-accessible, open items, which are (elegantly) downloaded into my ~/.local/share/fusesoc path and made available. However, I never manually requested those - they're automatically placed. That library now shows up in my library list, too - nested .core files behave exactly this way. Maybe I want to get rid of those nested files and specify my own library version (manually). I'd like to have the tool remove that library and all source files from the automatically-downloaded library.

In the case where an item is removed from any .conf file, maybe just delete and re-create the ~/.cache/fusesoc structure(s), too? This would impact the next compilation effort... but I think that's probably fine, too, unless a more elegant solution presents itself.

Does this clarify the case at all?

Anyway, great to have this issue raised. Let's finalize the spec

Absolutely.

[olofk]

That does clarify it a bit. The key here would be the separation of workspace-local and user-global libraries. Technically, ~/.config/fusesoc/fusesoc.conf should have a 1-1 mapping to libraries in ~/.local/share/fusesoc and by following that logic we could remove all libraries from ~/.local/share/fusesoc that aren't referenced by ~/.config/fusesoc/fusesoc.conf

I'm afraid however that it can be easy for various reasons to get those two sources out of sync for various reasons, and if someone has put their libraries from a local workspace in that dir they would be very confused about why it suddenly disappears. So I think it's safer and easier to implement a remove command with two options. One that just removes the entry from fusesoc.conf and one that also remove the library. This would still leave unferenced libraries around but I have no good idea how to solve that. Any directory can potentially be a fusesoc library. Maybe we could add a clean command (planning to do that for caches, more about that later) that would look go through ~/.local/share/fusesoc searching for libraries not mentioned in the user-global config file, and ask the user what to do with them.

Now about caches, there are a lot of things to improve here. existing cores should be validated to ensure the user didn't mess around with them (or they were partially downloaded) and there needs to be commands to clean out the cache. But let's open a new issue for the cache part (unless there already is one. Might well be the case)

So to sum it up, I think the most important aspect is to be able to deselect a library from a workspace. The second most important is to remove it when deselecting. For that we should have a library remove and a library remove --delete. The clean-up aspects will have to wait and we can create a separate issue to work out the kinks