Remove r2ghidra-sleigh (sleighs are now generated from r2ghidra direc…

[greenfoo]

Checklist

• Closing issues: #issue
• Mark this if you consider it ready to merge
• I've added tests (optional)
• I wrote some documentation

Description

WARNING: I am probably missing some context/background thus it is quite possible that this PR does not make sense. If so, please feel free to discard it.

While working on updating r2ghidra to include the latest decompiler version I found out that r2pm has two packages: r2ghidra and r2ghidra-sleigh.

The first one (r2ghidra) installs the sleighc compiler and the .so library while the second one (r2ghidra-sleigh) installs the .sla files for each CPU architecture.

The strange thing is that both of these packages reference the same git repository (r2ghidra) and use different "make" commands to obtain one thing or the other.

This PR unifies that:

• The r2ghidra-sleigh package is removed.
• The r2ghidra package no longer depends on r2ghidra-sleigh
• The r2ghidra build/install recipe is updated t generate/install everything (sleighc + .so + .sla files)

As I was saying at the beginning, I'm probably missing some context and there is a reason why today things are being done like that. In that case, please delete this PR.

Thanks!

[greenfoo]

By looking at other PRs (this one) it looks like the separate packages approach was taken because updating the sleighs might break things.

If this PR is merged the sleighs will no longer be "frozen" but always updated to the same version contained on ghidra-native.

On one hand, if this might break things, this will be an issue (and this PR should be discarded), but on the other hand, sleighs will always be sync'ed to the code that uses it in ghidra-native which, in turn, is sync'ed to upstream ghidra, which should be guaranteed to be always compatible, right?

Again... I might be wrong. If so, ignore this comment :)

[trufae]

The reason for having two separate packages for this was mainly to solve the problem on android and windows where building is expensive and you can switch between different plugins but keep or ship your own sleighs downloading them as zip.

I understand this is not the desired behaviour when building everything from git because there are no zips to use so i think the pkg may remain but probably not for all the situations. What do you think?

obviously the easiest way to solve that is to have a single pkg with no deps. But that will force us to handle the systems wrre building the sleigh is not possible or reasonable and the binary builds too

[greenfoo]

Ah! I understand now.

So... this is how it works today:

1. r2ghidra declares one dependency: r2ghidra-sleigh
2. When installing r2ghidra from Linux, the repo is downloaded and the library is built using Makefiles. Then, the r2ghidra-sleigh dependency causes a ZIP file with all the SLA files to be downloaded and installed.
3. When installing r2ghidra from Windows, two files ZIP files are downloaded: one with the precompiled Windows binary and another one with the SLA files. Then, the r2ghidra-sleigh dependency is triggered, but on Windows it is configured to do nothing.

With the change proposed on this PR, this is how it would work:

1. r2ghidra no longer depends on r2ghidra-sleig
2. When installing r2ghidra from Linux, the repo is downloaded and built using Makefiles. This now includes both the library and the SLA files
3. When installing r2ghidra from Windows, everything works as before (ie: two ZIP files are downloaded with the precompiled Windows binary and the SLAs)

Thus, the problem with this PR is that it is introducing an inconsistency:

• For Linux, the SLA files are generated from the same ghidra commit that was used to build the library
• For Windows, the SLA should also be the same ones, but for this to work the maintainer needs to remember to upload the expected ZIP files and update the references in the db.

In other words:

• Without this PR, Windows and Linux sleighs are always the same, but they might not be sync'ed to upstream.
• With this PR, Linux sleighs are guaranteed to be sync'ed with upstream, but they might be different from the ones you get on Windows.

And, unfortunately, on both options manual generation of the ZIP files is still needed.

I'm afraid I don't know how to fix this problem!
Both options have their pros and cons.
Whatever you decide should be good :)