More annoying default behavior

[W. Tasin]

Thomas Matelich wrote:
> 
Hi, 

I've inserted your 1st question to the FAQ-file of the kdevelop sources.

> Although nobody seems to have an answer for my last one...
> 
> 1)  How can I turn off the default installation of my executable?  It's
> somewhat annoying if you only have a library in that particular project.

Q: How can I turn off the default installation of my executable?
   It's somewhat annoying if you only have a library in that particular
project.
A: Unfortunately this isn't supported in KDevelop 1.x. But there is a
work-around
   for expert users. We will show this in a project example called
"check"
   Problem:
   Inside check/check/Makefile.am you find sth. like the following
content:
   --------
   ####### kdevelop will overwrite this part!!! (begin)##########
   bin_PROGRAMS = check
   check_SOURCES = main.cpp
   check_LDADD   = ./test/libtest.la

   SUBDIRS = docs test

   EXTRA_DIST = main.cpp

   ####### kdevelop will overwrite this part!!! (end)############
   bin_PROGRAMS = check

   # set the include path found by configure
   INCLUDES= $(all_includes)

   # the library search path.
   check_LDFLAGS = $(all_libraries)
   --------

   To change "check" to a non-installable binary you have to change all
   "bin_PROGRAMS = check"-entries to "noinst_PROGRAMS = check",
   but this would corrupt a part which is declared as overwritable by
kdevelop.

   Solution:
   Change check/check/Makefile.am to
   --------
   # kdevelop-pragma: custom
   ####### kdevelop will overwrite this part!!! (begin)##########
   noinst_PROGRAMS = check
   check_SOURCES = main.cpp
   check_LDADD   = ./test/libtest.la

   SUBDIRS = docs test

   EXTRA_DIST = main.cpp

   ####### kdevelop will overwrite this part!!! (end)############

   # set the include path found by configure
   INCLUDES= $(all_includes)

   # the library search path.
   check_LDFLAGS = $(all_libraries)
   --------
   Now the binary "check" won't be installed.
   TAKE CARE: This isn't recommended for the "normal" user, because by
inserting
   "# kdevelop-pragma: custom"-directive you are responsible for
updating this Makefile.am.
   KDevelop doesn't take care of it anymore.
   Especially if you add/remove a new file or directory to the
"check/check"-project directory
   (which normally updates this Makefile.am) won't work right anymore.


> 
> 2)  Besides the obvious solution of using -fexceptions, where can I turn
> off the default -fno-exceptions parameter to g++?

This question is already answered in the FAQ-file of the kdevelop
sources.
Here some answers...

Q: I´m developing an application which needs exception handling.
   How can I make it?
A: Edit the file configure.in in your toplevel source directory. Here,
you
   have to enter after the AC_CHECK_COMPILERS() macro:
     CXXFLAGS="$CXXFLAGS $USE_EXCEPTIONS"
   and after that you have to recreate your new "configure" by invoking
   "make -f Makefile.dist" at the toplevel source directory and then
restart
   the configure script
   (or inside KDevelop by using "Build/Autoconf and Automake" and
"Build/Configure...").

....

Q: Can AM_CXXFLAGS (inside a Makefile.am) be used for flags like -frtti
or
   -fexceptions?
A: No! In these cases there is an ordering problem. The standard
CXXFLAGS variable
   published by acinclude.m4.in already contains a -fno-rtti
(-fno_exceptions).
   If you did apply it to AM_CXXFLAGS the compiler command would insert
   these flags before the CXXFLAGS, e.g. here for -frtti:
   gpp ... -frtti ... -fno-exceptions -fno-rtti ......
   So the last flag (in this case, still -fno-rtti) will be used.
   KDE_CXXFLAGS instead will be inserted after the standard CXXFLAGS, so
it
   would look like:
   gpp ..... -fno-exceptions -fno-rtti ...... -frtti...
   and voilà it works fine.

   Take care: KDE_CXXFLAGS are only published by projects, which use
am_edit
   and acinclude.m4.

Q: Why patching configure.in with CXXFLAGS="$USE_EXCEPTIONS $CXXFLAGS"
doesn't work?
A: Look at the answer to the question "Can AM_CXXFLAGS (inside a
Makefile.am)
   be used for flags like -frtti or -fexceptions?" ;-)


Q: I am using CXXFLAGS="$USE_EXCEPTIONS" inside configure.in and it
works fine,
   why shouldn't I use this solution?
A: If you would use your version before AC_CHECK_COMPILERS() a call like
     CXXFLAGS="-pedantic" ./configure
   wouldn't work correctly.
   If you did use it after AC_CHECK_COMPILERS() the CXXFLAGS setted in
   AC_CHECK_COMPILERS() would be cleared.
   (For example in a "configure --enable-debug" call CXXFLAGS would be
    changed to insert also debug information to your code.)
   So please use CXXFLAGS="$CXXFLAGS $USE_EXCEPTIONS" instead.
   NB: Take care "$USE_EXCEPTIONS" has to be setted AFTER "$CXXFLAGS"


> 
> --
> Thomas O Matelich
> Senior Software Designer
> Zetec, Inc.
> sosedada at usa.net
> tmatelich at zetec.com
> 
> -
> to unsubscribe from this list send an email to kdevelop-request at kdevelop.org with the following body:
> unsubscribe »your-email-address«

-- 
The KDevelop project: tasin at kdevelop.de [www.kdevelop.org]
--
oohhh sveglia.... il mondo e' ammalato, ma x colpa di chi.........
(Zucchero)
:-------W. Tasin, FB
04,FHM-------------------PGP-KeyID:0x7961A645----------:
<Key-Fingerprint: 1610 835F 0080 32F4 6140  6CF7 A7D0 44CD 7961A645>

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