[sword-devel] I implore you...

[Jaak Ristioja]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm working on the patch but here's a short overview of the problem,
in case discussion is required. The problem is that source code using
Sword can't do stuff like:

 #include <sword/versekey.h>

This is VERY BAD, because we must do

 #include <versekey.h>

and provide -I/path/to/sword/includes/ to the compiler every time. The
problem with this approach is that versekey.h might also exist in
/usr/include or in other -I/include/paths. Additionally, this makes
the #include list rather incomprehensible, especially when we want to
sort it alphabetically. There's no telling what <versekey.h> refers to
- - is it part of Sword, part of something else, or a typo (e.g. maybe
this needs to be "versekey.h").

Why #includes like <sword/versekey.h> don't work is that the Sword
headers themselves use includes like <versekey.h> instead of
"versekey.h" which is correct. If I don't include -I/usr/include/sword
in my compiler arguments, but #include <sword/versekey.h>, the
versekey.h file tries to #include <swkey.h> which fails because it
can't find the file in in the include path.

The *.cpp files in Sword also need to use "" instead of <> to
distinguish between header system and local header files.

Afaik this is just best practice. Existing code using #include
<versekey.h> etc will continue to work as long as the
- -I/path/to/sword/includes exists.


Blessings,
Jaak

On 10.06.2013 19:21, Jaak Ristioja wrote:
> Actually I just remembered another serious flaw which causes a
> headache for developers using Sword. I'll write a patch ASAP.
> 
> Blessings, Jaak
> 
> On 10.06.2013 09:43, Troy A. Griffitts wrote:
>> Jaak,
>> 
>> I accepted and applied your header file patch nearly 5 months
>> ago.  Are you telling me that you still have 549 warnings from
>> SWORD headers?
>> 
>> Troy
>> 
>> 
>> 
>> On 06/09/2013 11:55 PM, Jaak Ristioja wrote: On 09.06.2013 23:21,
>> Troy A. Griffitts wrote:
>>>>> I don't think other developers are getting ignored.  Please
>>>>> be specific.  Just because I don't accept a patch doesn't
>>>>> mean a developer is getting ignored.
>>>>> 
>>>>> In fact, many times trying to make this release, when
>>>>> people complain that we need something fixed for this
>>>>> release, I ask for a simple testsuite addition to show the
>>>>> problem and desired result, and don't get a response.
>>>>> 
>>>>> I don't believe the problem is as you think it is Jaak.
>>>>> Many people whine about this or that. Not all whine for
>>>>> things to go in the same direction.
>>>>> 
>>>>> Everyone whines for a release but not everyone is willing
>>>>> to help submit tests and then fixes for those tests.
>>>>> 
>>>>> You stated that you would get involved to help, but you
>>>>> only submit things for which I previously told you I wasn't
>>>>> interested in accepting (worrying about pedantic warnings
>>>>> whose changes often make the code less readable and do
>>>>> nothing to improve any of the real problems for the end
>>>>> user.  Though I do appreciate a few of the warning fixes
>>>>> you submitted, a few being actual bug fixed too (thank
>>>>> you)-- I'm just ranting right now.)
>> As a BibleTime developer, I want to available tools (-Wall,
>> -Wextra, cppcheck, etc) to fix any errors in my code. Due to the
>> Sword header files which generate a lot of warnings this task is
>> VERY inconvenient. For example, when I compile the whole of
>> BibleTime with GCC, I get 549 warnings from Sword headers (mostly
>> for unused arguments) - how am I supposed to find the warnings
>> relevant for BibleTime? This alone often makes it a pain to
>> develop BibleTime and gives me enough reason to want to fork
>> Sword.
>> 
>> Turning on and fixing pedantic warnings will help find real
>> bugs. FACT! Forcing developers to work blindfolded will not help
>> anyone.
>> 
>> The same tools can be used to find bugs in Sword code, and
>> SHOULD regularly be used for this purpose to ensure code quality.
>> As is obvious these are currently NOT BEING USED by Sword
>> developers. However, when things eventually break, users complain
>> to the BibleTime project. Hence, it is also in the interests of
>> front-ends to ensure that the code of Sword is of good quality.
>> Again - if Sword won't work to ensure this and wont let us in to
>> fix things, we have another reason to fork.
>> 
>> This again leads us to the issue of attracting new developers to 
>> Sword. I don't want to write on this more than necessary to
>> provide a small argument for my conclusion. Afaik the current
>> situation isn't working well. Biggest obstacles for me personally
>> include working blindfolded, submitting patches by e-mail and not
>> getting enough feedback for (ignored) patches and other emails.
>> 
>> To conclude - maybe its just me, but altogether I really feel it
>> were easier to maintain a parallel fork (at minimal to provide
>> set of patches) than to waste my time writing long letters trying
>> to make this relationship work in its current form. I accept
>> whatever path the Sword project takes, but if it's not enough for
>> the needs of BibleTime and our devs, we will make our own choices
>> as well.
>> 
>> 
>> Blessings, Jaak The BibleTime team
>> 
>> 
>> PS: I apologize if this late-night response is incomprehensible.
>>> 
>>> _______________________________________________ sword-devel
>>> mailing list: sword-devel at crosswire.org 
>>> http://www.crosswire.org/mailman/listinfo/sword-devel 
>>> Instructions to unsubscribe/change your settings at above page
>> 
>> 
>> _______________________________________________ sword-devel
>> mailing list: sword-devel at crosswire.org 
>> http://www.crosswire.org/mailman/listinfo/sword-devel 
>> Instructions to unsubscribe/change your settings at above page
> 
> 
> 
> 
> _______________________________________________ sword-devel mailing
> list: sword-devel at crosswire.org 
> http://www.crosswire.org/mailman/listinfo/sword-devel Instructions
> to unsubscribe/change your settings at above page
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQgcBAEBAgAGBQJRtgDpAAoJEEqsYmEt1rCOkgU//jTliccCJwLcx/j31mRe8X8z
d+QKYaE4cABUcN9VH+k/3CZj52CwJWwxW8D0/5R2+r08S9fE5v9Qfc2Rm758TGXI
JjD1GjMmyLUhXDquBByc5UZbasVOGQElHalOOZd33rtX322NQI9h2xhUp6HBL9nV
+W8kn6jmrvnCaLlfKrfQs/Ky++ztM+3FC/ZsqKwmlazh44tHIIy25BmDBBDysvDI
EKGl77VTEByAR6rx+wHHxDFGaLpzT1zVarJ889EPtJ3iMmJ1uGC9pkzTwYJhT/+J
uQmNTRDLdryDrOVVvEjzz3LiechMJdSjn+xobvyxMLEKzEnsxPYFs5gCarlNDt2/
DgywGzrTtoGy2E9niNMpxAYphXLz7wFEm24Sm4WvQPn6RcQAnrvK5ERMnoOZE+5F
IHnj5rx++nZVBbTiJmXmCBjlAy7VXyHzu4iFlybHfCGUjQllZ9np5TFyVQ/JCDri
C9fDx6sOt5HKy8l4t2KNcSn8gBjg32PzSHMzHccVkRr+l5HhyteP7Y1dkSeKXRQG
jq/UNKR72Xlr6rEIeLelDnoNjlZy9LHiJ3uhxelecTLFJxyzUjX+sAB/MU7yc6T9
m7Hi4V2FsyI68CfhXTWzVRWYvbrEQBEenlzKYenNUkF123JqQn+VuTXPq3LDcdkW
eJUsL9nPvckZ/IGvr6ZJCDsNcSiP3wCsq/f66uu52r7ioSpB0AUeMpETuUqPzxcc
QitxpKPJzygWsjlTUH010oS3oz5PIwk+9ysHutRlCqL5wdRYJmYKoA1g533mbEUM
svE0J5TBcMP1BxxBye+xizen7YETl19j18I90ILhOPgFFwNoodRwZobkM5saZQan
pHQicxtjhvY0yHU3N6Zg37Yv5VBebI6u5hHiX1i5gemC5/lHxx2BLVywJPhnLwzC
GVYjIdxMiNjTX5duQwC+Z+JBGGPALRn/oHYA+hAw6d8nLAT5IBQm87DNiT6mCtXD
qsiWz3AXZR+DtSZPuZBB6ydkVvSrLRYgYi+4ymO8j2aP0zdtudoQHo7/T4jLKG14
j8d51TtgXd+nDmJgUEj4tMW3K5EsT17p78NcmpvLUY6rd6yQiAvij84HUkKPEQH3
QWFGw6/KPej/JPQBPfEfI3x7a863kF0ECbAONDvWW3xa+uELT+A+N5XYJqnfDX/R
Spu+7MbOpwO/AWnwbfR0AsiJrqVsxO0NHvCpqWnmUEfxwj40pKBW3KuttR37nfM1
zTWLrsuskFk/un4E0rH/Dcxc9Gfq183u5anvBfreECf+Q9+NP9sQmI+ZVlaroTdv
u3WJOdYSVYZj/rC8qQSn4lnXvY4Ig6qzFrCfdNHvsspyN1GjGMJU+RE9BCQp6Orv
j3t+8jRbQWNScxswIjJWAMM/P7NvRtQnb4LfRLx++/T+jOl53vOZohRs96fifdqZ
Bx7ikWMWbhJmUGxBj9ZG3NDHvF1EOAAjfaMd8fdn7C1TNU7VW6Ln5SyeMZCCVmJ9
5j9lPK5LV/Tw/O4w+Ljol9N915FJXgL0Ctim7PtwK9+n8yS+Wl0uL5VYYtZXKrpd
EDrEQWmFaTeGNlnXy7pKDwN+0B0+2xNJQnufQMmwfUwzju9oztgVmZjW++hEMEKm
plujraH0Ah5xRygKPqaCmnkxS48zfr2yYCdxQKKM04ux0EdtVnzD4k7jqqUA4vgf
tCpxumuMIvR03hn0nzucIsmMs55X6F4KrqN4oG+wWA8Ljc0arGIWboUeKWEiCFpH
lsyZhxE9Dx9n5Fi58+snQGLr7ZEAe4iudbSz3NgXEAdkHeLch4f8bkjdUZTVqnk5
eD4RBr/EZHWRa3qSwn1nwJWWfD977Px/51SLwSw3SxwPV8HZDyL6ObXw7m9X76pX
ukbqaHsS/hPJqZx5AqcdGjO9ASl7RvXinz6wa1fegSF6ylbBDPOyU8llBYLaV/Y8
KtNa+qNs8oaS+Amq3m70nmvqptw1slnw3CA8bc6IXAOgq96WzMlqsQ1zI0Jyzxbc
Ec7Vrhx0LyLwcfMSadYkn33eGe2GshKfVUh+LkPqZj9irDwgBV9TAkAG/jo2LHPS
I9udXXV9u6Upf1o8BmUSCDg+98KaB4V6KnOMZUzNvPdsBo9asRv6Lcvdy8/KTbb2
DKq9iuPGP3xLgpdZcpu1ojs8AHTm0a4+hoOxH5WxBGWsqlfVGSZPQGsHNaZaW+ww
WK+V1kR/IJNYlbAUy4aPkiFAtXobjBM8SgYB2NXsqtP6YOFUJSSQDfG2tkLwM718
UJYXN+LBAQnJ074HcDRaiX7e5yzmharbtsywhC+AMzVVXHQTFokQ1jHc2IYHhEfT
i1S9FG965GJOgqVu1qQFwnJsjhx0ZujkeQ82rQcB/b2NCbG8Yx5mZJ3TPcVaClbU
TWc4a3Vrfm8c6unPx88K773orsc1XOYyAzlVQl7dlxReY9Jy1CA+u1b8ElWiuVkV
EId9saFrC+Kp7/g4otOloeqJlgUleAamMQGXW+MbxrburdrPhjAzg3ts2HnYc9YU
2kwbBcYDse3bL2NQxYMNudfQ+HHkeVC6Xdk9MTNA/Snh93LkxVZ437dSgszC8mmI
1uVBCUqfPqBMDhEBY0eXNf4EblLD7Xm/pgbfliqOLNccIVmx9jW65inRiFOh3ttt
erNiAyLxhwAvQk4jtGFAnQQNz5Q5GBI02WXFji7pEja1H5lRMpoeUwEeSIUiOTwT
TmPNmAeZ0+Md62giLnOx
=qSm5
-----END PGP SIGNATURE-----