From kdevelop-devel Sat Aug 21 14:01:09 2004 From: "Steven T. Hatton" Date: Sat, 21 Aug 2004 14:01:09 +0000 To: kdevelop-devel Subject: Re: what is: http://www.kdevelop.org/HEAD/doc/api/html/gccoptionsplugin_8cpp-source.html? Message-Id: <200408211001.09562.hattons () globalsymmetry ! com> X-MARC-Message: https://marc.info/?l=kdevelop-devel&m=109309703014043 On Saturday 21 August 2004 08:14, Steven T. Hatton wrote: > http://www.kdevelop.org/HEAD/doc/api/html/gccoptionsplugin_8cpp-source.html > > I hit the above linked file while grepping the source tree for > 'no-exception'. It looks like code to provide me with an options list to > control compiler functionality, but I don't see the widget anywhere in > KDevelop. Grepping the source doesn't reveal any information about what > might be using it. It is clearly compiled, but It doesn't seem to do > anything. > > Any ideas as to what it is? I found the following in /download/org/kdevelop/repository/root/kdevelop/parts/appwizard/common/admin/libtool.m4.in on line 2671: # We don't want -fno-exception wen compiling C++ code, so set the # no_builtin_flag separately if test "$GXX" = yes; then _LT_AC_TAGVAR(lt_prog_compiler_no_builtin_flag, $1)=' -fno-builtin' else _LT_AC_TAGVAR(lt_prog_compiler_no_builtin_flag, $1)= fi That makes me believe the intention was to enable exception handling. ################################3 Then on line 4290, I find: # AC_LIBTOOL_PROG_COMPILER_NO_RTTI([TAGNAME]) # ------------------------------------------- AC_DEFUN([AC_LIBTOOL_PROG_COMPILER_NO_RTTI], [AC_REQUIRE([_LT_AC_SYS_COMPILER])dnl _LT_AC_TAGVAR(lt_prog_compiler_no_builtin_flag, $1)= if test "$GCC" = yes; then _LT_AC_TAGVAR(lt_prog_compiler_no_builtin_flag, $1)=' -fno-builtin' AC_LIBTOOL_COMPILER_OPTION([if $compiler supports -fno-rtti -fno-exceptions], lt_cv_prog_compiler_rtti_exceptions, [-fno-rtti -fno-exceptions], [], [_LT_AC_TAGVAR(lt_prog_compiler_no_builtin_flag, $1)="$_LT_AC_TAGVAR(lt_prog_compiler_no_builtin_flag, $1) -fno-rtti -fno-exceptions"]) fi ])# AC_LIBTOOL_PROG_COMPILER_NO_RTTI Which I read to say: "If you are using GCC set -fno-exceptions." #################################### Then on line 2791 of acinclude.in in the same directory I find: dnl AC_VALIDIFY_CXXFLAGS checks for forbidden flags the user may have given AC_DEFUN([AC_VALIDIFY_CXXFLAGS], [dnl if test "x$kde_use_qt_emb" != "xyes"; then AC_REMOVE_FORBIDDEN(CXX, [-fno-rtti -rpath]) AC_REMOVE_FORBIDDEN(CXXFLAGS, [-fno-rtti -rpath]) else AC_REMOVE_FORBIDDEN(CXX, [-rpath]) AC_REMOVE_FORBIDDEN(CXXFLAGS, [-rpath]) fi ]) Which looks like it is intended to explicitly prevent the user from setting -fno-exceptions and -fno-rtti: ############################################ Then on line 2952 of the same acinclude.in, I find: if test "$GXX" = "yes"; then KDE_CHECK_COMPILER_FLAG(fno-exceptions,[CXXFLAGS="$CXXFLAGS -fno-exceptions"]) KDE_CHECK_COMPILER_FLAG(fno-check-new, [CXXFLAGS="$CXXFLAGS -fno-check-new"]) KDE_CHECK_COMPILER_FLAG(fno-common, [CXXFLAGS="$CXXFLAGS -fno-common"]) KDE_CHECK_COMPILER_FLAG(fexceptions, [USE_EXCEPTIONS="-fexceptions"], USE_EXCEPTIONS= ) fi if test "$CXX" = "KCC"; then dnl unfortunately we currently cannot disable exception support in KCC dnl because doing so is binary incompatible and Qt by default links with exceptions :-( dnl KDE_CHECK_COMPILER_FLAG(-no_exceptions,[CXXFLAGS="$CXXFLAGS --no_exceptions"]) dnl KDE_CHECK_COMPILER_FLAG(-exceptions, [USE_EXCEPTIONS="--exceptions"], USE_EXCEPTIONS= ) Which looks like someone has a different opinion about -fno-exceptions ################################################ Then this on line 4157 looks like the sed is trying to remove -fno-exceptions: AC_DEFUN([KDE_CHECK_STL], [ AC_LANG_SAVE AC_LANG_CPLUSPLUS ac_save_CXXFLAGS="$CXXFLAGS" CXXFLAGS="`echo $CXXFLAGS | sed s/-fno-exceptions//`" AC_MSG_CHECKING([if C++ programs can be compiled]) AC_CACHE_VAL(kde_cv_stl_works, [ AC_TRY_COMPILE([ #include using namespace std; ],[ string astring="Hallo Welt."; astring.erase(0, 6); // now astring is "Welt" return 0; ], kde_cv_stl_works=yes, kde_cv_stl_works=no) ]) What's the off chance that these files have become a bit too large for anyone to effectively manage them? -- Regards, Steven _______________________________________________ KDevelop-devel mailing list KDevelop-devel@barney.cs.uni-potsdam.de http://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel