On Sat, 2009-12-05 at 00:03 -0800, Jonathan Marsden wrote: > 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.
Ok, I still don't think we've gotten to the bottom of this. Jonathan, in a previous message you said that this line errored out for you with a warning. Could you please try executing this from the top level of the SWORD source? g++ -DHAVE_CONFIG_H -I. -Iinclude -Iinclude -I/usr/include -DUSE_AUTOTOOLS -DUNIX -Dunix -D__unix__ -DSWICU_DATA= \"/usr/lib/sword/1.6.0_icu_4.0.1\" -D_FTPLIB_NO_COMPAT -D_ICU_ -g3 -O0 -Wall -Werror -D_ICU_ -ftemplate-depth-25 -DCURLAVAILABLE -I/usr/include -I/usr/lib64 -DUSELUCENE -g -O2 -g -Wall -DUSBINARY -c src/mgr/filemgr.cpp -fPIC -DPIC I do not get an error when building on various systems. > As indeed they should. Well, I disagree and haven't experienced normal -Wall actually report these-- as we're still trying to determine. I am open to being proved wrong, but I think both me and Matthew have reported that we don't have these reported, and only you have seen these. It's odd that you have seen these on multiple system, so I'm hesitant to say anything definite until we investigate more. Could it be some oddity with you .bashrc exporting CXXFLAGS or something? > 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 :) ... > But telling that me these > warnings are "crazy" seems unwarranted and unhelpful (and frustrating) > at this point. Please know I didn't mean anything personal about calling the warnings 'crazy'. Sorry, misunderstanding. 'crazy' was directed at the level of compiler warning, not at your acceptance of them. :) e.g., DON'T_WARN_ME BASIC_WARNINGS EXTRA_WARNINGS CRAZY_WARNINGS > >> 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've changed the README. Hope it better reflects the use for usrinst.sh > 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?? Gotcha. The configure default is obviously what the standard configure default should be. I think providing any '<insert_your_preferred_configure_name_here>.sh' is above what most projects provide. I agree maybe further changing the name to devist.sh or something might be a little more clear to people who try it, but most people don't read the README and thus will just ./configure && make or just used sword-devel packages provided by you! :) Honestly, I don't think it is a big deal. The things set in ./usrinst.sh currently are very minimal. Everything is standard to what users would need to set with any package they ./configure EXCEPT: --without-conf : doesn't install /etc/sword.conf on make install --with-icu : enable SWORD icu usage I supposed we could just change configure.ac to make these settings the default? I know other projects like Bibletime and Xiphos use their own Unicode frameworks (Qt and gtk+ respectively) instead of ICU. Thoughts? Are you enabling icu in SWORD now when you build packages? I supposed it doesn't really matter... they can still replace ICU with their toolkit of choice even if SWORD have ICU support compiled in, but there will be a dependency of ICU for libsword. Thanks for the discussion on this, and please know I didn't mean to say you were crazy for thinking these warnings were important. Troy _______________________________________________ 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
