I just filed a bug:
http://tracker.crosswire.org/browse/API-218
On 30.06.19 18:33, Tobias Klein wrote:
This is the CMake-related stuff that I find in the Sword sources when
searching for GLOBCONFPATH:
grep -r "GLOBCONFPATH" sword |grep -v ".svn"
./CMakeLists.txt:ADD_DEFINITIONS(-DGLOBCONFPATH="${SYSCONF_INSTALL_DIR}/sword.conf")
./cmake/README: * SWORD_GLOBAL_CONF - If this has a non-empty
value, then the option
"-DGLOBCONFPATH=${SWORD_GLOBAL_CONF}/sword.conf" is passed to the
compiler. If SWORD_GLOBAL_CONF is unset or is empty, then no
additional options are passed to the compiler. I believe support for
this is only half implemented at the moment. I believe that, if this
is set, then an actual sword.conf should be written to the directory
specified. At present this is not the case. I am unsure of the correct
default behavior if this is not specified.
So this explains that only /usr/local/etc/sword.conf is checked based
on the swmgr.cpp code posted below. Apparently GLOBCONFPATH is always
set when using CMake, but only to one directory, namely
${SYSCONF_INSTALL_DIR}/sword.conf.
I guess I could configure the CMake build using for example
-DGLOBCONFPATH="/etc/sword.conf:/usr/local/etc/sword.conf" when
invoking cmake.
Best regards,
Tobias
On 30.06.19 18:01, Greg Hellings wrote:
If not, please file a bug.
--Greg
On Sun, Jun 30, 2019, 18:01 Tobias Klein <[email protected]
<mailto:[email protected]>> wrote:
I'm happy about quick responses, no worries :)
I built Sword using CMake. No special options. Can I get the same
effect as with usrinst.sh and autotools, but using CMake?
Best regards,
Tobias
On 30.06.19 17:55, Troy A. Griffitts wrote:
Hi Tobias, sorry for the quick response. How did you compile
SWORD? If you use the autotools build system, be sure to
configure with the usrinst.sh script for standard release
configuration.
On June 30, 2019 8:31:52 AM MST, Tobias Klein
<[email protected]> <mailto:[email protected]> wrote:
Hi Troy,
I think there's problem with the global conf path (at least
on my box here ...).
This is the debug output I get:
LOOKING UP MODULE CONFIGURATION...
Checking for provided SWConfig("sword.conf")...
Checking working directory for sword.conf...
Checking working directory for mods.conf...
Checking working directory for mods.d...
Checking working directory ../library/ for mods.d...
Checking $SWORD_PATH...
Parsing /usr/local/etc/sword.conf...
Checking for /usr/local/etc/sword.conf...
Checking $ALLUSERSPROFILE/Application Data/sword/...
Checking $HOME/Library/Application Support/Sword/...
found (/home/tobi/).
Checking /home/tobi/ for mods.d...
Checking home directory for ~/.sword...
Checking for /home/tobi/.sword/mods.conf...
Checking for /home/tobi/.sword/mods.d...
found.
LOOKING UP MODULE CONFIGURATION COMPLETE.
What's striking is the fact that there's no check for
/etc/sword.conf (which exists on my system), but only a
check for /usr/local/etc/sword.conf.
This is what I found in swmgr.cpp (Sword 1.8.1):
122 #ifdef GLOBCONFPATH
123 const char *SWMgr::globalConfPath = GLOBCONFPATH;
124 #else
125 const char *SWMgr::globalConfPath =
"/etc/sword.conf:/usr/local/etc/sword.conf";
126 #endif
I haven't configured the GLOBCONFPATH for my Sword build, so
technically the globalConfPath should be the second one. But
for some reason it doesn't seem to check for the
/etc/sword.conf.
Can you explain this behavior and the above debug output?
Best regards,
Tobias
On 22.06.19 23:24, Troy A. Griffitts wrote:
Tobias,
You can do the same in your binary before you construct an
SWMgr:
SWLog::getSystemLog()->setLogLevel(SWLog::LOG_DEBUG);
and you should get more debug output from SWORD, including
its discovery of module paths.
On 6/22/19 12:57 PM, Troy A. Griffitts wrote:
Hi Tobias,
So, I've had a chance to try 0.8.1. I hope this feedback
is useful:
Wanting to test the SWORD configuration improvements in
the new build, I removed my ~/.sword folder. I have 5 or
so modules installed machine-wide under /usr/share/sword
so I was hoping those would be seen. Just to be sure
SWORD is configured correctly on my box, in my source
folder I go down into the examples at:
~/src/sword/examples/cmdline and run ./lookup yoyo yoyo
[scribe@localhost cmdline]$ ./lookup yoyo yoyo
Could not find module [yoyo]. Available modules:
[ESV2011] - English Standard Version with Strongs numbers.
[KJV] - King James Version (1769) with Strongs Numbers
and Morphology
[SahidicBible] - Sahidic Bible - Askeland / Schulz
[StrongsGreek] - Strong's Greek Bible Dictionary
[WHNU] - Westcott and Hort with NA27/UBS4 variants
On my previous test, using 0.8.0, I installed KJVA and WLC
which went into ~/.sword/ which is fine but wanting to
test more cleanly, I removed the ~/.sword folder completely.
OK, installed latest ezra package for F29 x86_64.
It created ~/.sword and an empty mods.d and installMgr
folder underneath. All fine. No sword.conf. Good.
Launched ezra-project.
To my surprise, I see my two previous modules available in
the dropdown AND the KJVA is showing data!
So, I could image a bug if you maybe cached available
modules someplace and didn't re-read SWMgr between app
restarts to see what modules were available, but I can't
imagine how you can still lookup data for both of my
previously installed modules since I have removed
~/.sword/ where they were installed and these modules are
not available in my system-wide /usr/share/sword library.
:)
Hope this initial feedback is a little useful,
Troy
On 6/21/19 1:06 AM, Tobias Klein wrote:
Hi all,
Ezra Project 0.8.1 has been released. This is a bugfix
release.
Ezra Project is a topical bible study tool.
https://github.com/tobias-klein/ezra-project/releases/tag/0.8.1
Noteworthy improvements are:
* Support for all languages of ISO-639-1/2/3. This
enables the usage of all the available Sword modules.
* Added sync functionality for Sword modules that have
been installed by other programs. Those modules are
now also available in Ezra Project and synced on
start-up.
* Do not use custom sword.conf anymore.
* Static Sword library now included. This means that
Ezra Project will run on more systems, because there
is no specific dependency on Sword packages anymore.
Downloads are available for:
* Ubuntu 18.04 + 19.04
* CentOS 7
* Fedora 29
* Windows (tested on Windows 10)
Feedback is appreciated!
Best regards,
Tobias
_______________________________________________
sword-devel mailing list:[email protected]
<mailto:[email protected]>
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list:[email protected]
<mailto:[email protected]>
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list:[email protected]
<mailto:[email protected]>
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
--
Sent from my Android device with K-9 Mail. Please excuse my
brevity.
_______________________________________________
sword-devel mailing list: [email protected]
<mailto:[email protected]>
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list:[email protected]
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: [email protected]
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: [email protected]
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
