[sword-devel] -O3 -g

[Troy A. Griffitts]

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