<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Thanks so much for your time in trying this out and testing,
Karl! Comments below:</p>
<div class="moz-cite-prefix">On 9/4/26 6:24 PM, Karl Kleinpaste
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:c4d24b79-4cdc-41bb-9111-92ee305bb49b@kleinpaste.org">
<div class="moz-cite-prefix">On 9/1/26 10:13 PM, Troy A. Griffitts
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:8b1b949a-fb28-43d5-98d6-deb8248619b7@crosswire.org">
<p>Have you tried building against SWORD master head?</p>
</blockquote>
<br>
Making all in tasks<br>
make[2]: Entering directory
'/home/karl/src/bible/sword/examples/tasks'<br>
</blockquote>
<p>Ah, yeah, I think examples/tasks has an example Makefile which
builds against the installed libsword and headers. I'm not sure
much changed there, but I would maybe try a sudo make install in
~/src/sword/ (if you don't have any other libsword installed on
your system) and see if the examples/tasks folder can build with a
simple `make`. Actually, I'll add some logic in there so the
Makefile can still be used as an example for someone building
simple sword apps. I'll check if it is within the sword build
tree and use the lib and headers there if so, otherwise use
pkgtool as it did.</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:c4d24b79-4cdc-41bb-9111-92ee305bb49b@kleinpaste.org">g++
-O0 -g -Wall -Werror `pkg-config --cflags sword` findHeadings.cpp
-o findHeadings `pkg-config --libs sword`<br>
findHeadings.cpp: In function ‘int main(int, char**)’:<br>
findHeadings.cpp:50:64: error: ‘SEARCHTYPE_ENTRYATTR’ is not a
member of ‘sword::SWModule’<br>
50 | ListKey results = module->search("/Heading",
SWModule::SEARCHTYPE_ENTRYATTR, 0, &scope);<br>
|
^~~~~~~~~~~~~~~~~~~~<br>
make[2]: *** [Makefile:11: findHeadings] Error 1<br>
make[2]: Leaving directory
'/home/karl/src/bible/sword/examples/tasks'<br>
make[1]: *** [Makefile:401: all-recursive] Error 1<br>
make[1]: Leaving directory '/home/karl/src/bible/sword/examples'<br>
make: *** [Makefile:633: all-recursive] Error 1<br>
<br>
I disabled examples and the build succeeded.<br>
<br>
I'm more than a little surprised that the generated swversion.h
has a <i>lower</i> version stamp than what came in via git clone.<br>
<br>
git df<br>
diff --git a/include/swversion.h b/include/swversion.h<br>
index 9e29ca58..d8bd086b 100644<br>
--- a/include/swversion.h<br>
+++ b/include/swversion.h<br>
@@ -3,7 +3,7 @@<br>
* swversion.h - definition of class SWVersion used to compare
version<br>
* info<br>
*<br>
- * $Id: swversion.h.in 3765 2020-07-26 10:31:09Z scribe $<br>
+ * $Id$<br>
*<br>
* Copyright 2001-2013 CrossWire Bible Society (<a
class="moz-txt-link-freetext" href="http://www.crosswire.org"
moz-do-not-send="true">http://www.crosswire.org</a>)<br>
* CrossWire Bible Society<br>
@@ -24,12 +24,12 @@<br>
#ifndef SWVERSION_H<br>
#define SWVERSION_H<br>
<br>
-#define SWORD_VERSION_NUM 1090003908<br>
-#define SWORD_VERSION_STR "1.9.0.3908M"<br>
+#define SWORD_VERSION_NUM 1090003802<br>
+#define SWORD_VERSION_STR "1.9.0.3802"<br>
#define SWORD_VERSION_MAJOR 1<br>
#define SWORD_VERSION_MINOR 9<br>
#define SWORD_VERSION_MICRO 0<br>
-#define SWORD_VERSION_NANO 3908<br>
+#define SWORD_VERSION_NANO 3802<br>
<br>
#include <defs.h><br>
SWORD_NAMESPACE_START<br>
<br>
</blockquote>
<p>Hmmm. Thanks for pointing this out. Since git doesn't have an
incrementing revID like SVN had, we reworked this to use a 'count'
of commits in the git repo. It's kludgy but should be an ever
increasing number that doesn't mean much except larger is newer.
I've fixed it so it should never be less than our last SVN ref id.</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:c4d24b79-4cdc-41bb-9111-92ee305bb49b@kleinpaste.org">
<blockquote type="cite"
cite="mid:8b1b949a-fb28-43d5-98d6-deb8248619b7@crosswire.org">
<p>I'd love to know if I've ironed out the HTTP installation
preferences in the engine as we move toward a release.</p>
</blockquote>
<br>
It appears to work; I reinstalled some modules from Xiphos repo
and watched the web server log, and also a couple from Crosswire.<br>
<br>
However this will induce a significant change to the mod.mgr,
because for 25 years it has managed only local directory sources
(intended for e.g. cdrom-provided content) and FTP/HTTP/HTTPS
sources in the Add/Remove/Load Standard panel, and consequently is
losing all the xyzPackagePreference entries when adding or
deleting an entry of my own. So we will have to make a Xiphos
update to fix this before the next Sword release.<br>
</blockquote>
<p>So, I think the InstallMgr class can manage the sources for you.
I believe there is an InstallMgr::saveInstallConf() If we're not
keeping the HTTPS?PackagePreference lines, please let me know and
I will look into it. If Xiphos is using their own save routine, I
understand, but please let me know if we need to fix something on
our end.</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:c4d24b79-4cdc-41bb-9111-92ee305bb49b@kleinpaste.org"><br>
<blockquote type="cite"
cite="mid:8b1b949a-fb28-43d5-98d6-deb8248619b7@crosswire.org">
<p>xiphos.org (though I couldn't find an HTTPS URL so I had to
fallback to <a class="moz-txt-link-freetext"
href="http://ftp.xiphos.org/pub/xiphos/"
moz-do-not-send="true">http://ftp.xiphos.org/pub/xiphos/</a>)</p>
</blockquote>
<br>
There is no HTTPS on ftp.xiphos.org. Port 443 is ... otherwise
occupied, when it is occupied at all.<br>
<br>
- Are you aware that, in the Windows build (that Greg provides in
the process of building Sword for Xiphos), <a
href="https://github.com/crosswire/xiphos/issues/1280"
moz-do-not-send="true">lucene indexing fails for locked modules</a>?<br>
- Have you ever looked at the peculiar problem of <a
href="https://crosswire.org/pipermail/sword-devel/2026-January/050930.html"
moz-do-not-send="true">lucene search failing randomly when there
is not an arbitrary trailing space</a>? <br>
</blockquote>
<p>I did see this last one and Cyrille sent a patch which we merged:</p>
<p><a class="moz-txt-link-freetext"
href="https://git.crosswire.org/main/sword/-/commit/78211c48f5a645975602c85f29c7fb2b10edca94"
moz-do-not-send="true">https://git.crosswire.org/main/sword/-/commit/78211c48f5a645975602c85f29c7fb2b10edca94</a></p>
<p>I hadn't heard of the lucene indexing fails for locked modules
problem before now. I would guess something is odd in the module
or we had a problem in earlier releases. Not sure. The only
datapoint I have right now is that we have the NA28 module locked
and I have an unlock key I used for that for swordweb and it was
indexed with mkfastmod on May28 this year using SVN HEAD at the
time. I'd be curious if the latest head fixes anything and if the
problem is windows-only or also on linux.</p>
<p>Thank you again, my friend! I really appreciate your time and
great work on a new release!</p>
<p>Troy</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:c4d24b79-4cdc-41bb-9111-92ee305bb49b@kleinpaste.org">
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
sword-devel mailing list
<a class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:sword-devel@crosswire.org" moz-do-not-send="true">sword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext"
href="https://crosswire.org/mailman/listinfo/sword-devel"
moz-do-not-send="true">https://crosswire.org/mailman/listinfo/sword-devel</a>
</pre>
</blockquote>
</body>
</html>