what is: http://www.kdevelop.org/HEAD/doc/api/html/gccoptionsplugin_8cpp-source.html?

Steven T. Hatton hattons at globalsymmetry.com
Sat Aug 21 16:03:05 UTC 2004


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 <string>
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




More information about the KDevelop-devel mailing list