After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 742208 - libenchant fails to find modules (backend libraries) when used within bundle
libenchant fails to find modules (backend libraries) when used within bundle
Status: RESOLVED FIXED
Product: gtk-osx
Classification: Other
Component: modulesets
2.0.x
Other Mac OS
: Normal normal
: ---
Assigned To: GTK Mac Integration Maintainers
GTK Mac Integration Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-01-01 22:30 UTC by Igor Mammedov
Modified: 2015-01-31 18:39 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
make enchant to look for modules/configs in env specified dirs (3.01 KB, patch)
2015-01-11 11:34 UTC, Igor Mammedov
committed Details | Review

Description Igor Mammedov 2015-01-01 22:30:31 UTC
I'm porting claws-mail to gtk-osx, and it uses libenchant as front-end
for spell checking. So when bundled claws-mail is used on another
system (i.e. there are no libraries at hardcoded build prefix) it fails to
find libenchant_myspell.so (inside the bundle) and other back-end
modules since it looks for them either at homedir or a hard-coded
installation prefix, the same goes for system-wide default
ordering config.

See
-DENCHANT_GLOBAL_MODULE_DIR=\"$(libdir)/enchant\"
-DENCHANT_GLOBAL_ORDERING=\"$(datadir)/enchant\"

providing env. variables to recognize additional directories (inside bundle)
for backend libraries and default ordering config seems like a convenient
way to ship them with bundle so that user won't have to do
manual magic installation steps to make spell-checking work
except of installing needed dictionaries.

As for dictionaries, it's looking for them at
 /Library/Dictionaries
as it's currently  built.

Dictionaries probably shouldn't be shipped with mail client anyway,
but rather installed by user when he/she needs them either at
global /Library/Dictionaries or user's home directory.
Comment 1 John Ralls 2015-01-02 00:00:47 UTC
You need to attach your proposed patch here.

I get it. I was misled by "config", which isn't appropriate in this context. That's not your fault, it's on whoever wrote that bit of enchant. 

For the global ordering part, I'd prefer that you use XDG_DATA_DIRS because it's the more general approach and it's already bound to $bundle_data in the launcher script. It's a PATH-style variable, though, so you'll have to split it on ':', append "enchant" to each, and add it to the list. If that's too much work you can use the special variable as in your original patch, but call it ENCHANT_DATA_PATH instead of ENCHANT_CONFIG_PATH. See http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
for why.

For finding modules ENCHANT_MODULE_PATH is fine.
Comment 2 Igor Mammedov 2015-01-11 11:34:27 UTC
Created attachment 294269 [details] [review]
make enchant to look for modules/configs in env specified dirs

Here is amended patch that uses XDG_DATA_DIRS for ordering config lookup instead of ENCHANT_CONFIG_DIR as suggested.
Comment 3 John Ralls 2015-01-28 00:32:32 UTC
Comment on attachment 294269 [details] [review]
make enchant to look for modules/configs in env specified dirs

Committed, thanks.