unwanted g++ flags in 2.1.4

Boris Gorelik bgbg at pob.huji.ac.il
Fri Nov 29 10:26:35 GMT 2002


Thanks!
I'll try this as soon as I return from my vacation ;)
Boris
----- Original Message -----
From: Tarjei Knapstad <tarjeik at chemcon.no>
To: <kdevelop at kdevelop.org>
Sent: Thursday, November 28, 2002 10:50 AM
Subject: Re: unwanted g++ flags in 2.1.4

On Thu, 2002-11-28 at 08:32, Boris Gorelik wrote:
> Hi all!
> I've recently tried to compile a code I had written several months ago
with
> kdevelop 2.1.0 (which used to compile without any problem). Now I'm using
> kdevelop 2.1.4, and the code doesn't compile. A quick look on compiler's
> messages reveals:
>
> g++ -DHAVE_CONFIG_H -I. -I. -I.. -Wnon-virtual-dtor -Wno-long-long
> -Wbad-function-cast -Wundef -Wall -pedantic -W -Wpointer-arith
>                                                    ^^^^^^^^^
> -Wmissing-prototypes -Wwrite-strings -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOUR
CE
> -Wcast-align -Wconversion -O2 -O0 -g3 -Wall -fno-exceptions -fno-check-new
 -c
> -o atom.o `test -f atom.cpp || echo './'`atom.cpp
>
> Which means  that the compiler uses -pedantic option that apparently
wasn't on
> the previous compiles. The problem is that I couldn't find an appropriate
> menu to cancel this behavior (since it's much easier to cancel -pedantic
then
> improving the code ;)  ).
> Can anyone throw a hint?

Yup, throw acinclude.m4 (in your project root) into an editor and strip
out all the stuff you don't want. Rerun "Autoconf and automake" and
"Configure" from within KDevelop and you should be set. (Repeat the
edits in acinclude.m4.in in the admin directory if you plan to
regenerate this file). Removing the -pedantic and warning flags is not
the right way to get rid f warnings though, as I'm sure you are aware of
:)

On the other hand, why those default defines (_BSD_SOURCE and
_XOPEN_SOURCE=500) and all those flags are enabled permanently is beyond
me. I suppose these are supposed to be there when developing apps for
KDE, but why not leave these as default _project options_ instead of
slamming them into acinclude? Not all of us are using KDevelop to
develop KDE stuff (yes, I actually use exceptions among other things)
besides the fact that everything should be configurable from within each
project. Will this be fixed in Gideon?

--
Tarjei




-
to unsubscribe from this list send an email to kdevelop-request at kdevelop.org with the following body:
unsubscribe »your-email-address«



More information about the KDevelop mailing list