newbie question #2: plugin-based applications

[Alec Leamas]

On 03/07/18 16:55, John Stebbins wrote:
> On 07/03/2018 04:49 AM, Alec Leamas wrote:
>>

>> Still ashore, got things working. I have not really sorted out all the
>> pieces, but fixing the version (which I had worked around by publishing
>> opencpn as 1.6. Ouch..) and reverting to json seems to settle things.
>> Filed a bug about the yaml parsing (179).
>>
>> Now, I need to patch opencpn to load plugins also from
>> /app/extensions/lib/opencpn. This is perfectly doable, just some time to
>> get into that code.
>> But, I also need to patch any plugin flatpaked to use their own text
>> domain (with locales under /app/extensions/share/locales) and also to
>> get their own data from /app/share/opencpn/plugins instead of
>> /usr/share/. I'm not really looking forward to this...
>>
>> So: is there any way to merge e. g., /app/lib/opencpn and
>> /app/extensions/lib/opencpn? Or some other approach?'

My problems partly stems from the fact that opencpn as distributed
contains a small subset of plugins. These are installed with the /app
prefix which becomes problematic when new plugins arrives installed
under /app/extensions (and /app/lib et. al is read-only).

I can work around this by dropping the plugin subset in opencpm and
package them as a separate extension. All plugin files will then be
under /app/extensions/lib , /app/extensions/share, etc, and by making
symlinks in the main package this should be transparent.

> In general, any app (or plugin) should always look for such things (locales and own data) in $PREFIX/share/blah... 
> where prefix is set with the --prefix option of configure.  Any app (or plugin) that doesn't do this needs to be *fixed*
> with a patch anyway and patch pushed upstream ;)

Agreed for everything but the locales, see above. As for the locales, I
just don't get it. Both the plugins and the main program uses the
gettext libraries (and the default domain).  They run in the same
process, and gettext only uses a single base dir for locales.

This is no problem in regular packaging, all locales (even plugins)  are
installed under /usr/share(/locales. But here, we end up with two sets
of locales, one under /app/share/locales and one under
/app/extensions/share/locales, right?  Which isn't that simple for
gettext to handle (?)

Of course, I could patch plugins to use a specific domain or so. But,
anything which must e done in each plugin just isn't attractive..,.

> Note that when building a flatpak extension, flatpak-builder for some reason I don't understand sets --prefix=/app by
> default which would cause a problem.  But fortunately it supplies a correct FLATPAK_DEST variable which can be used to
> set the prefix configure option correctly when building modules.  E.g.
> 
>             "build-options": {
>                 "prefix" : "${FLATPAK_DEST}"
>             },

Thanks, I have seen this without understanding it. Got around it by
hardcoding the extension prefix, this seems much better.


Cheers!

--alec