Troy A. Griffitts wrote: >> ./autogen.sh && ./usrinst.sh --disable-debug && make
>> displays all the warnings, so the current SWORD build environment is >> actually turning *off* some warnings by default > I'm not sure I understand why you are seeing this behavior. You are > correct that the *plan* was to -Wall -Werror for debug builds. OK, I > think I know now why.... If I comment out --enable-debug in usrinst.sh > then things work as I would expect. Without debug is the default, and > --enable-debug is provided if you want otherwise. I've never actually > tried EXPLICITLY saying --disable-debug and I'm not sure why EXPLICITLY > saying --disable-debug turns on your crazy warnings... Is this some > oddity with autoconf? I'll try it commenting out --enable-debug in usrinst.sh. No difference. For me it works the same commenting out --enable-debug and using --disable-debug. On Ubuntu 9.10 amd64, and on Fedora 12 amd64 (I created a Fedora 12 VM, just for you :) , both ways of building SWORD generate warnings, just as long as debug is turned off. As indeed they should. As GCC has, since at least 2007, for these classes of coding error. They are not "mine", and I don't think they are "crazy" either :) Please just fix the SWORD code to check return values when it calls functions which are designed to sometimes return error codes and which in some cases (notably write()) are designed to have your code retry the write in such cases... These warnings are happening on Debian, Ubuntu and Fedora 12 systems just by commenting out the --enable-debug option in usrinst.sh, or by using --disable-debug as a parameter to it. On SWORD's current svn tree. I'm really not sure how much more I can do to demonstrate their reality to you -- must I test on CentOS, OpenSuse and Mandriva too :) I'm perfectly willing to work with you on better ways to check these result values that meet your own coding standards, etc. etc. if my patches do not measure up. That's fine. But telling that me these warnings are "crazy" seems unwarranted and unhelpful (and frustrating) at this point. >> I'm not really sure *why* --disable-shared would be >> considered "normal", by the way...? > Cuz while developing I've been bitten too many times by trying to > debug a problem with a binary pulling in the WRONG libsword.so. I > like to know my lib is linked directly in my binary to avoid this. OK. So again, that's "normal for SWORD developers" or "normal for Troy", but not "general public normal" or "public release normal" :) >> I'm also not doing --libdir=/usr/lib64 which seems a very odd default. > Aren't most systems running 64 bit these days? I don't know, I suspect many Linux users still run 32bit. Not all Linuxes that are 64bit use this lib64 directory convention. And some (few) users run Linux (and so SWORD) on other architectures completely. > Fedora uses /lib64 and /usr/lib64 by default on these systems, and > Ubuntu at least symlinks /lib64 and /usr/lib64 to /lib and /usr/lib > respectively, so we should be good on both distros with this. I think it's ugly and unnecessary, and makes creating i386 packages difficult. It's probably fine for you, as a personal default. It may even be fine for most SWORD developers, if they all have 64bit machines. But not for "normal" or release builds, IMO. Do remember, SWORD is being built on hppa, mips, powerpc and s390 these days (I rather doubt we have hordes of SWORD users on IBM s390, but the packages definitely exist!). Why make a path convention used by only some amd64 Linuxes the default for all architectures?? >> Maybe usrinst.sh needs renaming to developerinst.sh (or even >> troyinst.sh), making its target audience clear, and then a usrinst.sh >> more aimed at real builds / real users can be created and included, too? > :) I'm serious -- developerinst.sh and usrinst.sh would provide both sets of options for two different audiences, at very low cost to the project. Or developerinst.sh and releaseinst.sh , if you want to make a "clean break" from the old (and apparently confusingly targetted) usrinst.sh. Jonathan _______________________________________________ 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
