Closed domschrei closed 4 years ago
Why creating a package mechanism if mist distros already have one build in ;-) What I man by that is that you could create deb/rpm packages and support by this most distros.
I have tweaked the installation for https://github.com/alex1701c/krunner-vscodeprojects recently, so krunner gets killed automatically when the package is installed and the KDE frameworks version used to compile gets set as the minimum version in the package.
Maybe you can take this as an inspiration?
Cool, thanks for the pointer! That really helped, I learned a lot from that CMakeLists.txt in your project.
I'm somewhat happy with the packaging now, I added packaging of .deb plus a generic installer script. I'll directly flag a release to that so that I can link the precompiled packages in a clean way. Maybe I'll take a look at further packaging options later.
Hi all,
as suggested by @alex1701c and also to advance #15 / #17 , I tried creating a packaging mechanism for this plugin using CPack. At some parts it is quite hacky because I am inexperienced with CMake in general and specifically with CPack.
In the current state of this branch, running
sudo bash package.sh
should create a self-extracting archivekrunner-symbols-1.0.4-Linux.sh
containing the binary plugin and all other necessary files. Then, runningsudo bash krunner-symbols-1.0.4-Linux.sh --prefix=$install_prefix --exclude-subdir --skip-license
will extract and install the plugin.However, the directories to which these files are installed are fixed during the execution of the package script, which is problematic if these directories vary among users. Maybe CPack should instead be configured to produce a "flat" archive of all files needed such that a separate script can then install each file individually to the correct system-specific directory.
Anyway, I appreciate any feedback or tips for improvements. I may continue playing around myself a bit on this branch before merging something that is hopefully functional in general.