1

I am working on a C program that has a plugin architecture. We build and package both .rpm and .deb packages.

Some plugins have additional non-binary resources, such as image files, or script files that only apply to that plugin. Those additional resources are in the put in the same directory as the plugin's .so file. So the plugins need to know where they are located on disk, and in their same directory, be able to open their associated files.

Is there a standard, or at least more-or-less idiomatic, way of doing this?

Note that I am wary of hardcoding paths such as /usr/lib/<foo>/plugins, especially since some distros like to use /usr/lib64 vs /usr/lib.

Additionally, during development, the program (and/or plugins) are not installed in standard locations. They are executed out of a source code subdirectory in the user's home folder, and the plugin folders are in a slightly different relative location from the binary under development in these cases.

Edit: For a concrete example, the source tree for project foo has a plugins directory. Some standard plugins that are shipped with with foo are maintained in the plugins directory. One of the plugins, pyconsole, relies on foo_pycon.py, which is also in plugins\pyconsole\ directory.

During development, I might have several copies of the repo in my home directory, for different work on different branches. One working copy might be in ~\src\foo_branch\.

I invoke that locally-built instance of foo by: ~\src\foo_branch\release_x86_64\bin\foo. foo locates all the plugins in a relative subdirectory, including ~\src\foo_branch\release_x86_64\lib\plugins\pyconsole.so.

Is there a standard or idiomatic way for this particular instance of pyconsole.so to know where it is located, so it can open and use its own foo_pycon.py?

Note that when installed via packages, the relative paths are/might be different. Where as /usr/bin/foo is the location of the installed binary, we install our plugins under /usr/lib[64]/foo/plugins.

  • 2
    seems to me that graphics, sound files, etc. would belong under /usr/share/appname and not in /usr/lib – ivanivan Oct 4 '17 at 16:20
  • @ivanivan Probably right. I think that's probably acceptable if I modify the packaging for existing plugins. But what about script files, such as custom Python scripts to initialize and setup the custom built-in Python interpreter that is added by a plugin? The Python script is checked into the source repo, and is very much "part" of the plugin. – scottbb Oct 4 '17 at 16:25
  • You coudl go with something like /usr/share/appname/plugins/pluginname and put EVERYthing in there, with corresponding ./lib ./share etc. directories for each pluginname directory. But at this point I'd say read over the FHS for the "ideal" location and follow that practice as best you can. – ivanivan Oct 4 '17 at 17:39
  • 3
    Libraries could be stashed as /usr/lib/appname/... (mailman does this) or /usr/libexec/appname/... (various things on RedHat use this) but I'd definitely put the images and whatnot under a share dir, not lib. You'll probably also need an ENV for the user override. – thrig Oct 4 '17 at 17:42
  • 1
    @scottbb The suggestion by thrig, to have an environment variable available for overrides, seems like a fairly solid approach to me – Fox Oct 5 '17 at 7:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.