On Wed, Jun 12, 2013 at 2:51 PM, Jaak Ristioja <j...@ristioja.ee> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi! > > What's the integration status on this patch? > > Blessings, > Jaak > Can we allow changes which are not bare-minimum build-breakers, such as restructuring the includes, be a later issue for the next next release and just get 1.7.0 out the door, please? Also, what prevents you from having -I/usr/include -I/usr/include/sowrd and then having #include <sword/foo.h> and having it all work just as planned? --Greg > > 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@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@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@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@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@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@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----- > > _______________________________________________ > sword-devel mailing list: sword-devel@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@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
