Page MenuHomePhabricator

Make extension directory more easily configurable at compile time
Open, MediumPublic


Huggle expects to find extensions in /usr/local/share/huggle/extensions. This path is hardcoded in src/huggle_core/definitions_prod.hpp, which is then copied to definitions.hpp and included. The CMakeLists.txt file for each extension and Huggle itself also hardcodes that extensions should be installed to share/huggle/extensions unless it's building for a snapfile.

I help maintain the Arch Linux User Repository package for huggle. The Arch package guidelines prohibit installing to /usr/local/ and strongly recommend installing executable plugins to subdirectories of /usr/lib/. Putting ELF files in /usr/share/* is considered a packaging error. To comply with these guidelines, I must patch 9 separate files across 8 different Git repositories. While the patch for definitions_prod.hpp is reasonable enough, patching across Git submodules gets messy fast.

It would make Huggle easier to package if the extension directory in the CMakeLists.txt files could be configured with a cmake parameter.

Event Timeline

Petrb triaged this task as Medium priority.Jul 22 2020, 1:30 PM
Petrb added a subscriber: Petrb.Jul 22 2020, 1:33 PM

I am wondering how we could implement this, so that this path can be specified on one place only. Because it needs to be defined both in Huggle source code somehow (so that Huggle knows where to look for extensions) as well as CMake so that it knows where to write the compiled extensions.

I am just wondering - are you using CPack to create that arch package? Or do you have some custom script? If you have a script then this shouldn't be that hard to automate, I am for example solving similar problem in Windows world using these scripts: you can see I am also relocating the compiled extensions in the end

The AUR package is described by this PKGBUILD, which is fundamentally just a fancy bash script that does

make install

I'm currently fixing the issue by applying a patch, which is less than ideal. I'd of course prefer if the extension directory could be changed without editing files, but if that's not feasible I'll probably switch to sed at the next release.