-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Troy,
Imho there are already header files which clash, namely the zlib ones: $ `echo -n 'ls -ld '; find include/ -name '*.h' | sed -e 's_^include/_/usr/include/_'` 2>/dev/null - -rw-r--r-- 1 root root 15292 sept 24 2012 /usr/include/zconf.h - -rw-r--r-- 1 root root 87011 sept 24 2012 /usr/include/zlib.h Jaak On 13.06.2013 11:32, Troy A. Griffitts wrote: > Jaak, > > On 06/13/2013 10:12 AM, Jaak Ristioja wrote: Troy, > > It still seems that you missed one thing. Namely, the #includes > with <> still include a prefix, i.e. sound/ and omniORB4/. The > Sword #includes do not, and this by itself is a big problem which > makes header filename clashes a lot more probable, especially if > other libraries would follow suit and have the same #include > convention as Sword does. >> Jaak, I didn't miss this. > >> As I said in my last email, I'm not saying your wrong. I'm just >> saying: > >> a) the headers I looked at include things DIFFERENTLY than your >> patch, so I'm not sure your fix is the most standard. b) things >> work right now on a ton of platforms and compilers and build >> projects, and I don't want to change this just before a release, >> which could potential break all of these-- especially if there >> are no known problems with this right now. There is no reason to >> push a potentially disruptive patch just before a release. > >> Also, if you use pkg-config to get the compile and link >> directives, you shouldn't need to care about what to pass to the >> compiler. > >> .cpp: g++ `pkg-config --cflags sword` $< -o $@ `pkg-config --libs >> sword` > > >> Thanks for being concerned. I understand your concern and value >> your input, Troy > > > > Regarding <> and "", the latter provides a better safeguard > against including the wrong headers in some situations, especially > when dealing with multiple versions of the headers being installed > at the same time. More commonly, using "" instead of <> can also > help to simplify the build system for libraries such as Sword. > > I don't consider using <> instead of "" a bug. But what I think is > very inconvenient is that one has to explicitly use > -I/usr/include/sword/ instead of just using #include > <sword/stuff.h> in the source files. > > This is cause for confusion for developers, who might think (as I > did and do): 1) Do I need to #include <stuff.h> // Sword header ? > 2) If I #include <sword/stuff.h> then why do I need to pass an > extra -I argument to the compiler? > > What I'm asking is that even if you don't want "" instead of <>, > please use a sword/ prefix for all respective #includes in all > header files of Sword. > > Blessings, Jaak > > > On 13.06.2013 09:47, Troy A. Griffitts wrote: >>>> Jaak, >>>> >>>> I'm of the same mind as Greg. Our include syntax has been >>>> working as is for 20 years on a number of compilers and >>>> platforms. I hesitate to wholesale change this now because >>>> of 'in principle' arguments without any actual problems being >>>> seen. I don't have time to compile your changes on all the >>>> platforms we support to test them. I know what we have now >>>> works. >>>> >>>> I'm not saying that you're not right, but I also don't see >>>> your changes as standard. Just a brief look on my box, >>>> /usr/include/sound/sfnt_info.h includes >>>> /usr/include/sound/asound.h with: #include <sound/asound.h> >>>> >>>> /usr/include/omniORB4/anyStream.h includes >>>> /usr/include/omniORB4/omniTypedefs.hh with: #include >>>> <omniORB4/omniTypedefs.hh> >>>> >>>> Just the first 2 I looked at. >>>> >>>> I'd like more time to investigate this before making a >>>> change, >>>> >>>> Troy >>>> >>>> >>>> >>>> >>>> On 06/12/2013 10:28 PM, Jaak Ristioja wrote: >>>>> Well, using -I/usr/include/sword is just an ugly >>>>> workaround. It doesn't change the fact that Sword headers >>>>> include each other in a wrong manner (using <> instead of >>>>> ""). Because it would only be a workaround, we do not want >>>>> to stick to it forever. We want this fixed. >>>>> >>>>> Secondly, headers in the Sword include directory have a >>>>> greater chance of colluding with other headers in >>>>> /usr/include/ and elsewhere. Hence the Sword headers >>>>> themselves might include wrong header files if that >>>>> happens. That's why using "" instead of <> is important so >>>>> that relative paths would be searched before any locations >>>>> specified by -I arguments to the compiler. >>>>> >>>>> I don't believe my patch broke anything, the main changes >>>>> were substituting <> with "" when #including Sword headers. >>>>> However, if it did break anything, it should be easy to >>>>> amend. I'm highly motivated to get my patches applied to >>>>> the next version of Sword one way or the other. So just ask >>>>> and I'll fix it. >>>>> >>>>> Blessings, Jaak >>>>> >>>>> >>>>> On 12.06.2013 23:05, Greg Hellings wrote: >>>>>> >>>>>> On Wed, Jun 12, 2013 at 2:51 PM, Jaak Ristioja >>>>>> <j...@ristioja.ee <mailto:j...@ristioja.ee>> wrote: >>>>>> >>>>>> 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 >>>>>> <mailto: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 >>>>>> <mailto: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 >>>>>> <mailto: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 >>>>>> <mailto: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 >>>>>> <mailto: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 >>>>>>> <mailto: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 >>>>>> <mailto: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) iQgcBAEBAgAGBQJRuYcrAAoJEEqsYmEt1rCO2dBAAJmo5vimBUbV9Oj8eA6QOvR3 kj79xjqsWouPTuoV5fv5oYqO8KH3S03IzTIR5NjjYQ0gBJSstIE2bfvAwlUnTzkq 5+6/ZQiqLyK1mpMn/Hs1ykze5eV6bKz+bM+9gY2PvI/ftTiPf5inob9iLdU+pv0Z mh6SGgkv21F3o0S/rWIxGEQM4em59IEbjYqxwniHnq8Icmr3ln2xbu3AObZziAVS qLg/PHQaYrL1P6E7YetynO4gWqFAqFb5vK/7Jd55qsYLP2XdAP2nUUD5ftMBkils WFbFZgj3G+6zfQdCo385WROzc6++AUGqXHsFvg0FvpHn5bDQ+66JiifSaykibU9G cZerJ9yFWB6CyX+E1L7FTsZKkf4RHzwmv86OCXiJAJhECfHAnyKFK4Dp+2Z3oVNw ME6e4DTmJuPQOEUI4BF2o5rd2HzxxzRZzonzkrpfXkH0DbRJNuZqL6xQVX3Eefen hCENogvrBT9ZKG1Uq24denYJMSXLaS3JI2il4SruTMGML/ODvUnQ5uTPkoxUICJt /e/El7vIPwIxLbNOTDiSg+d80c7Uo7Ro3tWOGkN0Qw640arLf11RFu1qeALJRHqK Wsew6bZzpRZ1U07XXLLAakkIdCfxMW7xfaV4vouSOn5oxROK2I4joFdat1N/ykAD /7y4uGk8Zbz2/X4gfl84rDvfDo73TVxTrHcVREmwIc2JKP7YUR5k1FOBbEt7y3jd 9p17l/D8SzIkFdKF+/0hsz0o4rSJIQqD5AByPihDtQ3ECIwxtcC9q/xD8RbzL4cg B2QDJ5xUI1v2nWmQNzXn2RH5zYKARQWlmLJEwiyQA1DPk+U8TewRY/4dBU7C2JAA E5KhC4lbB8sbBWj3o/qqs4MWXDfBgHI3jHjH5+0UVQj/ucSI/8uSVasy/LU16g4Y PUbqDC9fNh/JtINj0Yi3IRnpg8et6Jdiy1kuzcPhVUne9er3Yd9VqywNS/uB1sMF mNU3T+nXdkR8MnK7XQ0eCN3UPVj2Nk7+m+9PqY05agVWQSUxuwYt9gApiLZYIfJg sTPKtx+uGQqJ4abRrGN9DGdM6bEG7rT1xG0CduJDwWrPHXv/AvXeGiZh4Qhs4jG4 6na7BY+yR1UpCHj9N8Qj3IS69BVmB63TMfEts135i4tChX0HIHi4fdNuhKcoK5pe 7hfEgD6D5rQKtbb5x1w9RlDUddeh/4ksuxo2/QFGPliKr5VhEsthUF3HS+IF4jRE bdHZQyBjSbNITKMwTCyQt/pVeypBf7ZiNB7z6TbflDA1riwgQOuHCrkOi+t2BiK6 WQvm2GkEYn0ePQQVSlt87srYZw1NCLjoNkU2pVDfMGdtmSsUAXgP5UqgCDbO+gFP 61zwWYr4GJ3CiYThgtZifybTN3efL4eQyNNLgziPrgKqE85D4KEI5F5C9cU32c+k vLrjBQgx2ss6ICsaCoDrFpoqfqQFhTYK8FYRJileigWR7sBislhnP/MM/4QGUiOu A1GaaJNuu1aHrqB5+ff3LtdOg37BaZmB6tdjOxV3nrRADL+rEm3FBiU+9sbTartd qckR/xTHYq9nBJ+BgYCgeq7O6U40AItLFE9WTWIFsGAU6Ve4FrDwYQa67syYtEkN byQpgD9/hg5fKeMbYZcmEmNPcdb99cLc43qUVv3UcavzbJhV+iuefLTSUpoUqOOa N02MmnT0y0iEPYxFeWTnXu4gmgv0FH9SuPPa8riwXaBnPEkSrhOaztApJAIj+d2M ZAXalwIHK3wd6k2S9dTysCKIqfv4THAbZoVPkG49f0ThN5E5hzsgfVsZX8wbqbPk qp/nl3/BYMeuddHtqzJYapJ4FJvB0g119MhnBz0bnXLWOlXJpborni39CjwSEZqz cfFep3DHISyo2uQ1GqSn1qKAU9h3mMBAtfNQofQsZ3rKoXVtllhPG85bHBS7MupD MxrxQtKIQLxS0xF2eeUg86bjzX7aP/ojoNuliGsV2AXO2DAbu/EVHPMJofI6mY7R qdpg6hGTldIPI3smkFJKEL57f9O1rVsegmGIJoTloDX/qOXQg6D74C3tG6hST64v B5dNGLF/h+PQAcC7TTiBPkIOPVzjXiqyup2zsqkIwCkWKYOHXTbUXr5yDVdKFEiB cTsTa5DUlRbMJPfb9LCdcnHzkUCmukYBDtZA1omBIFP2B5kaZ9oosjVuYqMiJqfw xbVW2JZCOcUkGG31wE5xYEFJkCCfDH+KJ3O2TEsS+af2I9D8mDYZY1sEzOuEJZ88 EW1N1VuxMyXzlhvahjnEr2mjsdYGVdC8bI4tBGjLBcrZ1AEKJItcpYhvugOJkTo4 hXHcWyz5IfOGfw8Yv4cFRKwUCcUztv5wmu8ZI0dXeaIGFphwelF/dwCiPcyN9FwF fRudqSds6crUmMt3zgHHTzL35HYzh5UOZocGzCkW0Q1O+z6CaY80xUQOrJIvkU9l 8IUL7ePRsNDz3ZPMJaYvnVFHdmi5Y29Y9+GfyNsoSoyfhtbWoIqGWTt4OYazUBGu 1YQ3lum2Fix6ZjLI3THXUJhzfUt2rL76n+ulk8G3W88iDXHHvYoN7yWSx28bWBBp pJmiiBWKa5p1ESADG3LXQ2sdDKpCrDpUaSbf2rf/gJGvomgcfKVxd8cJ4PfJYIsZ j6YFDUOqnGf1/YnQo7GZ55AgLok2DQRTBkIFJbZiElkG7rwHEa6awUaftoT0m171 /Si9mQmShWYoKvkbUWsP =jSzY -----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
