make installation easier
williballenthin opened this issue · 7 comments
Despite being familiar with Ghidrathon development, there have been times that I've avoided using Ghidrathon because its a pain to install. When I visit a project and see that I have to compile software from source I am much less likely to experiment with it (probably due to past experiences when the compilation failed, and I'm stuck debugging the build process).
We should investigate how to make Ghidrathon easier to setup and use.
In a perfect world, I think I'd want to see: users download a single file from GH releases page, put it in a specific directory, and everything just works. How close can we get to this ideal?
Today, users must:
- have JDK installed, for Ghidra, out of scope.
- have Ghidra installed, obviously.
- have maven installed, for build recipe.
- have C/C++ compiler installed, for building JEP.
- have Python installed, for building JEP.
We ask users to build JEP (from source?) so that they have access to a jep.dll that works in their environment. The resulting jep.dll is copied into an extension .zip file so that it can be loaded by Ghidra.
The things that might influence jep.dll working are:
- OS: Linux, macOS, Windows
- architecture: x86, ARM
- Java version
- Python version
We should investigate the above environment matrix to figure out exactly what is/nt compatible. For example, I suspect that the Java version is generally not related to jep.dll working.
I suspect that we could pre-build jep.dll for all supported variations of the matrix (OS, architecture, python version) and package them into a single pre-built Ghidrathon.zip extension file that is released on Github. If Ghidrathon is able to determine the installed python version at runtime (and OS and architecture, more trivially), then it can select and load the appropriate jep.dll.
removes: maven dependency
requires: python installed and configured
requires: python pip install jep (which requires C/C++ tools) for python module
However, as noted above, we still require the user to type pip install jep so that the python-land JEP dependencies are available. And, that builds the jep.dll, so build tools will need to be available.
Alternatively, we could ask users to install JEP via pip and Ghidrathon searches for the resulting jep.dll in the python path. However, JEP doesn't distribute pre-built jep.dll files (nor wheels, today), so this would still require users to have a few additional dependencies (C/C++ compiler).
removes: maven dependency
requires: python installed and configured
requires: python pip install jep (which requires C/C++ tools) for python module
However, from a user perspective, this isn't any different from the first proposal. From a developer perspective, the Ghidrathon.zip is smaller and the CI/CD workflow simpler since we don't have to build jep.dll for our users. There's a bit more complexity in finding the jep.dll, since we have to implement python path enumeration.
I think this is a pretty good solution.
Anyways, with the above strategies, the user setup looks like:
- install python (and optionally virtualenv)
- pip install jep
- download Ghidrathon.zip into $ghidra/Extensions
Which is getting close to ideal. I'm not sure its possible to have Ghidrathon install the python JEP module into python-land (but no native build) without a bunch of complexity; however, I might be missing something. Maybe there's something cool to be done with PyInstaller to distribute a standalone package of Python, though this wouldn't allow for futher installation of packages, so its not a good solution.
Thoughts?
In both the above scenarios, it would be nice if Ghidrathon prompted the user for the python path (autodetect system python or activated virtualenv, enable overriding with a virtualenv) during installation. This way users can be very explicit about where they want to load python from and where JEP should be installed.
Alternatively, we could ask users to install JEP via pip and Ghidrathon searches for the resulting jep.dll in the python path. However, JEP doesn't distribute pre-built jep.dll files (nor wheels, today), so this would still require users to have a few additional dependencies (C/C++ compiler).
From my understanding, this is the default behavior already no? build.gradle appears to pip install jep to the current python environment and configure_jep_native_binaries.py copies the corresponding jep binary to the ghidrathon/os/<arch> directory for build.
i could be wrong and I'm on mac too so it might be different for windows.
yes, you're right, but my point is that asking users to do a gradle build is not ideal. i'm proposing that users download a prebuilt .zip of ghidrathon and put it directly in their Extensions directory. in this scenario, the extension doesn't get unpacked/repacked to include the dll.
ah, that makes much more sense yes.
This should be addressed in 32f3969 - please reopen if you continue to have issues after this is released.