[sword-devel] I implore you...
Jaak Ristioja
jaak at ristioja.ee
Wed Jun 12 12:51:44 MST 2013
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi!
What's the integration status on this patch?
Blessings,
Jaak
PS: Is Troy the only one with access to apply this?
On 10.06.2013 22:49, Jaak Ristioja wrote:
> Argh, someone must have changed things on SVN lately, so this
> patch was invalid for the current trunk... I wish you guys would
> learn git or something. Anyway, here's something which should apply
> to SVN 2819, I hope.
>
> SHA1SUM: 071a4fb64f1d0c2ed5d746d08791592f76eaf633
>
> Blessings, Jaak
>
> On 10.06.2013 22:34, Jaak Ristioja wrote:
>> Attached is a patch for this. Please apply.
>
>> SHA1SUM: 9a99e34ce419ea3288a32148d431ec971fb0e675
>
>> Blessings, Jaak
>
>
>> On 10.06.2013 19:38, Jaak Ristioja wrote:
>>> 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
>
>
>
>>> _______________________________________________ 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.20 (GNU/Linux)
iQgcBAEBAgAGBQJRuNFMAAoJEEqsYmEt1rCO29k//AoJs/O+4El40pOJ7Vnnk6LJ
DTD07ykOWMdJLpfqXyxsao8vEdCGSZUp2HArHw+B/1bsnuQtdq5jObUngPUj2RBL
VqQDJ2f8miNl9nc7Og6wM3zz34r647lE9sxm9gnCC/wiH3SivGJMUMy9Z1AprKNb
bDwArC5dGMhi55+qrSdxSBpqhA2lod9MHYY/1avAqHP7ftY1Na1PzC9wujMWEhW8
LJvYp8+s/m6hgfBPy45dB0n/TXJZQegRuKWaue3UKXudYWteWctSFj2TnCrWaar3
6Rt6nE5X0pdkh4x7R6Du1vxk55d/JTsoYzQcb8sAT1GqRt5JKxoNLrZKQ0EuQLoj
ItHANgEOtGNjfNN/j9qWl3WIPSxaXCe/FTgj36zJDRcpI2y5rUFjqK+lCEa9Pc29
aWr4I0NwnRvHtrArizEH2rUk7kF0Ah8KN+rRpI/vq8Ikalr/GoCVfBHsB6cOHyol
e3qeClxMJE2rObqE40w1fH1k/DDXkka8WBQOqV09iZvgL+BjqZY2HBVnYS84VnwM
KRhPOVJM+es5oB2LtrnK2D0ZTbiiyKf8lEPS/FZVbmq1AYQ1q3e0RsY+X9qZiz0L
p4wuZIDPLs4xlo0SIGLMP/dAdnlGQo2lFLrVcHE3n/D/6ylG1dZgpEMluc9/iEx3
0flkixwbYkULFoZ3GERb8KuXT/82JIKZy37AzGqq1smmi3A47qKCfmDyg1daDiJP
ic9kbj69MiGgqCSTHscSDGjnkcwNY8cRe95laoWny7IsnEKDvpQoeIyoNvjrHo0e
Pln0KxXhrDHRlE3iDy0KsHtEFpw56KL2ToFyUuJX15mh0H+M74xxnqBIHoS9V8/f
/JVcDUedMiVlrFRERPlQ6DKF6BlMNUlW/59jzSAyW0zSG0QgnXxB7Z9LFprOa7wM
9FG+h5EjLH6odMqiX2HowFFApzvZWPp90IIPl+Bvk5uWBguNEiK8+Eoz2IeD+p1V
L8LVYruNIgXqgeKdIodtIw+Ru1PBIVwdGzSn6hm5PhUAEdL56fwTm9lvR5Frk4Cz
Ua0HcllvZMsmUwouShGfIi13wIAc85onrU257h3uLQcomnNvl/nQlJtYrOcydi4D
qQVp3X7h1ZKm87MG5rKUhAQBhA2eA/9VhnFejuZMdZQalzIYDVw1fZU7JzXr1+cq
YZSsr/kNRE1oMiFkY4GouMbcmXM6DQ0WQ3Zmc4o070POCqmtS97RXRq0+Ah3S09N
06aGfHpSfFcoXI6KF4g5SRv4EUAjzH996Y+aS2rF2bOCV9ttluoTdqB+OC651jV5
oABRuXNVmbJ5Ea9yd45AOKwhZgAwr3zht68XeiUcWW3pctgUjFHHF0WXnmh9QWIF
kcRd+bSXXqJ0QYjkLc2Y/d8ylpv3C0/dLQSgnMmODUnRSGtc4hnFdTnw6DYzOhmQ
RbjZd5GmgcpMfzCb9tzpNOSyhodUwmJA2WukaAh5yJcb5tvJaOWDcQXekc81Zg/3
EDyZT6EqvZU2XqVluAchE+cvAVfGOmQ1e7vWYCAYYRE9jEbD7JmHw2Pzl8s/Znzt
yqWldVa84K/8Eg1MD4JfxJUbnkMjtWzD+fi6VH4y9Tydqm8N8f+Q0ZUpRFtJ/fLe
TU+qGlxpDjnM7VM5uVGPQaF5G3tAxafuw+i+6wjP9ZPTJ9r0BxkwwMra11si/kB1
aMh4pJzr0nKlo5cafM5ke2BsLx5wdl+Hd0xQn3qXVP8ZDOVWqjz7XTy1DyN2fPya
WJaRfFXjLuCwxzV/RUJxynDH0jsI/wsP28+2TU9/jFL1CncBIBH6uHGyPhEK04Gv
yCwZYX4iB/UVIPFp7g+G/pEHZTy5dR0GuL838F1oN8OSMdbGfn33Kb4U1+lAB4LP
Nw/qEuci+2TDdo7C7emueU7QiT0WFRhAol8BlNbc/B7ndzve+Oeb+AQkPe1sAzlT
CT87N8ZFM4mcC238LI24Smks4y59Mug6sSja6psdsPf1QXePnDOThZBqYIKxkRmh
r0Ej3SdjfhnZ4uvIQXeqhQtSylUe+2dDn7m57I9u3fEg6qz3RqBAvgC1wowwqEhi
F7oajohRaesc3U/yDT0U2loL+XdhIiySsRcpkF6C/+ci/zpGjJ2k/E3ahpf8EfBf
2QtDEky0OBYb+c2As5oQzqTuLg9xhbx6eSZuB4VEQnrIVjd7U1+MmDw1F4eC2fsQ
EXkDHZ4ztTdxhqd6EOIvm04M/z6+IzbX6Eppe5w8JdbGYTgXfJ2XRZjPp3OtKwOO
BN+/ChTDbO1G96KrbbiEomNRiYUf2Be2NGFpdgWH/zs5n3AwjpS0e0z4h3U6n7wj
1cQvzq7VBupQhWPRNsf3Sxmh9Ly8X8NRXMkIAl32qNLwhggc0mpckbBZgxlZFRRE
SorKNN1KbbBi0q9hq3PWscB12W7UAZatpQ02eHLaPwlRL6MmgdpIn0oGgt07smlT
rG2VwKAVhuyCJ92+LL/rWdWgp5J9P/P4toXqAj9dlkoOvtkQ4XTYv3uIvaXwcLWI
esLWijNn9wAAlsMQ8EWR1f6aHhu+e7h2FOqPnuIRl/8I4JJgbpDNdhxD9PmkWr3z
Ve0RYrte+WVCnEbbV8elN3VaNypsFcTLiwvEBgYIWGPK0ZjlCJdFesRM6bvs17tI
DPQTv7NB+Fmt4/Tr6QUgbXX1jiU5xjiVNEN5CIWQUrdGc+Nh43yv429HAGgSJ9F9
ecLbhzbKZUxBFpygcqtD
=kxGp
-----END PGP SIGNATURE-----
More information about the sword-devel
mailing list