how to turn off -fno-exceptions in kdevelop

[W. Tasin]

Alan Hilton wrote:

Hi,

 > Hi everyone
 >
 > Have been following this discussion with some interest as it is relevant
 > to something I'm attempting to do.
 > I'm a real newbie to kdevelop and automake/autoconf but am experimenting
 > with the generation of Linux kernel modules.

this discussion runs a little bit outside from your problem,
because you are making a c-project (as far as I can see) and this
project type doesn't set the CXXFLAGS, we were talking about.
Anyway now follows the long long answer, since it cannot be handled in
3 sentences.

 >
 > The only way I have been able to achieve this so far is by placing
 > default %.o:%.c rules etc.in Makefile.am as shown below.
 >
 > I have two initial questions:-
 > 1) This approach is presumably incorrect as it bypasses
 > automake/autoconf?
 > 2) Is there a better or alternative method of getting the CXFLAGS KFLAGS
 > etc.into the project which gives a more rounded solution?
 >

First at all you are bypassing KDevelop, because it cannot
handle more than one target inside a project directory.

You are trying to create a binary, which should be installed in the
bindir (setted by --prefix= of configure - on default /usr/local/bin)

and also a static lib (which will not be installed -> see
noinst_LIBRARIES).

My first question also, why don't you create a subdir inside your
project/project directory to have the following structure:

project
   :---project  (that's where your testprogram resides)
         :------ test (that's where the lib resides)

The disadvantage of your structure is that every source you are creating
will be placed to be linked also to the static lib (see run_tests.c
inside libtest_a_SOURCES)

------------


 > ####### kdevelop will overwrite this part!!! (begin)##########
 > noinst_LIBRARIES = libtest.a
 >
 > libtest_a_SOURCES = timers_test.c task_manage_test.c
 > task_extension_test.c task_control_test.c sema4_test.c run_tests.c
 > msg_q_test.c
 >
 >
 > EXTRA_DIST = msg_q_test.c run_tests.c sema4_test.c task_control_test.c
 > task_extension_test.c task_manage_test.c timers_test.c
 >
 > ####### kdevelop will overwrite this part!!! (end)############
 > bin_PROGRAMS=run_tests
 > INCLUDES = -I/usr/src/linux/include -I/usr/src/rtai/include -I..
 > KFLAGS = -D__KERNEL__ -DMODULE
 > CFLAGS = $(INCLUDES) -Wall -Wno-unused -O2 -g -MD -fno-strength-reduce
 >
 > # Uncomment this line to enable debug comments.
 > CFLAGS += -DZDEBUG
 >
 > run_tests: run_tests.c
 > $(CC) $(CFLAGS) -o $@ $<
 >
 > # Default rules
 > %.o:%.c
 > $(CC) $(CFLAGS) $(KFLAGS) -c -o $@ $<
 >
 >
 > Any advise gratefully received.
 >
 > Alan Hilton
 >

Anyway... let's assume you need this structure (knowing that KDevelop
cannot handle this correctly) the default way to make a Makefile.am
would be:

------------
####### kdevelop will overwrite this part!!! (begin)##########
noinst_LIBRARIES = libtest.a

libtest_a_SOURCES = timers_test.c task_manage_test.c
task_extension_test.c task_control_test.c sema4_test.c run_tests.c
msg_q_test.c

EXTRA_DIST = msg_q_test.c run_tests.c sema4_test.c task_control_test.c
task_extension_test.c task_manage_test.c timers_test.c

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

bin_PROGRAMS = run_tests
#### following line was edited manually
run_tests_SOURCES = run_tests.c


------------

If you would now create the Makefiles by invoking "make -f Makefile.dist"
and "./configure" and search inside project/project/Makefile for the
standard rule to compile, you should find:

%.o: %.c
         @echo '$(COMPILE) -c $<'; \
         $(COMPILE) -Wp,-MD,.deps/$(*F).pp -c $<
         @-cp .deps/$(*F).pp .deps/$(*F).P; \
         tr ' ' '\012' < .deps/$(*F).pp \
           | sed -e 's/^\\$$//' -e '/^$$/ d' -e '/:$$/ d' -e 's/$$/ :/' \
             >> .deps/$(*F).P; \
         rm .deps/$(*F).pp

And you can see some difference between your rule and the created one
(e. g.: dependencies checking, handling of shared/static libs with libtool).

-------------

Now to the second point: including defines

As we all know now ;-) from the mailing list that the flags included by
KDevelop are session flags and will not be exported to the Makefile.am
or configure.in(.in)
(due to the complexity and possibilities of Makefile.am:
BTW: we ALWAYS need help also for this topic! ;-))

I can see two types of DEFINES a necessary one "-D__KERNEL__ -DMODULE"
and a developing one "-DZDEBUG"

the first one is obligatory to the directory, so simply add manually
to the Makefile.am:

AM_CPPFLAGS=-D__KERNEL__ -DMODULE

-----
The -DZDEBUG one:

Now the question: Should the end-user know about this flag or not?
If you want this flag only for your own debugging purpose, so you
already have the possibility to include this by KDevelop in the proper
dialog (session-flag).
By commandline, either with:
CPPFLAGS=-DZDEBUG configure
or
make CPPFLAGS=-DZDEBUG

But if you want the user to set this flag, so it is well done if you
would export this flag to configure.
That requires a switch for configure like --enable-extra-debug=

To include this you have to know something about writing m4-functions
and shell scripting in a limited way (sorry, no way either).

I would include the following to configure.in after the line
"dnl KDE_MISC_TESTS" (take care: different position of the following
part can create different configure scripts - so test it):
--snip--
AC_MSG_CHECKING(for extra debugging)
AC_ARG_ENABLE(extra-debugging,
[  --enable-extra-debugging        enable extra debugging],
[if test "$enableval" = yes; then
   enable_xdebugging=yes
fi],
enable_xdebugging=no)
AC_MSG_RESULT($enable_xdebugging)

if test "$enable_xdebugging" = "yes"; then
   AC_DEFINE_UNQUOTED(ZDEBUG)
fi
--snip--

and publish the usage of the define ZDEBUG inside acconfig.h having then:
--snip--
/* Define if the C compiler supports BOOL */
#undef HAVE_BOOL

/* this one is for debugging purpose */
#undef ZDEBUG

#undef VERSION

#undef PACKAGE

/* Define if you need the GNU extensions to compile */
#undef _GNU_SOURCE
--snip--

After this you have to update your configure script and your Makefiles
(by KDevelop menus "Build/Autoconf and Automake" and "Build/Configure..."):
You will then find the ZDEBUG-Flag defined or not inside config.h
(which was created from acconfig.h), last but not least you have to include
"config.h" inside your sources, which uses the ZDEBUG flag.


--------------

If you think that was complicated... now
the third point ;-)

There are at least three solutions to handle absolute include-pathes:

First the way you did:
INCLUDES=$(all_includes) -I/usr/src/linux/include -I/usr/src/rtai/include

which is only for this project directory another one wouldn't have these
setted (I think a bad solution).

Going further here's the second solution:
adding them to configure.in to publish them for the whole project and
to every subdir which has INCLUDES=$(all_includes) inside its Makefile.am.
To do so substitute:
---snip---
all_libraries="$all_libraries $USER_LDFLAGS"
all_includes="$all_includes $USER_INCLUDES"
AC_SUBST(all_includes)
AC_SUBST(all_libraries)
---snip---
to
---snip---
all_libraries="$all_libraries $USER_LDFLAGS"
all_includes="$all_includes $USER_INCLUDES -I/usr/src/linux/include 
-I/usr/src/rtai/include"
AC_SUBST(all_includes)
AC_SUBST(all_libraries)
---snip---

Now the only problem is that these pathes are fix.
I don't know much about rtai (the Realtime Application Interface?), but 
I guess (maybe not now but in a future version) it can be also compiled 
inside /usr/local/src/rtai (or another location).
So another one using/building your project may have some problems
to put this always under /usr/src/rtai (e.g. less rights or already
installed in another location by your sysadmin, build rtai for another 
linux-kernel etc.).

Wouldn't it be nice to have this switchable by configue, searching the 
default pathes for presence of RTAI and alert the user if it isn't found?
So you have to write again a macro/shell function for configure.in:
instead of:
---snip---
all_libraries="$all_libraries $USER_LDFLAGS"
all_includes="$all_includes $USER_INCLUDES"
AC_SUBST(all_includes)
AC_SUBST(all_libraries)
---snip---

you should have

---snip---
dnl ---------------------
dnl perform rtai checking
dnl

dnl use a cached value, so the next time we can do a configure w/o the 
option
dnl   (so we are using an var name beginning with ac_cv_ ....)
AC_CACHE_CHECK(for RTAI, ac_cv_rtai_includes,
[
   AC_ARG_WITH(rtai-dir,
     [  --with-rtai-dir=DIR       where RTAI is installed ],
     [  ac_cv_rtai_includes="$withval"/include
     ])

   dnl >>> here is the directory list which will be searched for rtai.h
   rtai_incdirs="$ac_cv_rtai_includes /usr/src/rtai/include 
/usr/local/src/rtai/include"
   AC_FIND_FILE(rtai.h, $rtai_incdirs, rtai_incdir)
   ac_cv_rtai_includes="$rtai_incdir"

   if test "$ac_cv_rtai_includes" = NO; then
     AC_MSG_RESULT(not found)
     AC_MSG_ERROR([RTAI cannot be found. Please check your installation! ]);
   fi
])

dnl >>> don't forget the -I prefix for the directory
rtai_includes="-I$ac_cv_rtai_includes"
dnl >>> publish this flag to all Makefiles
AC_SUBST(rtai_includes)

all_libraries="$all_libraries $USER_LDFLAGS"
all_includes="$all_includes $USER_INCLUDES $rtai_includes"
AC_SUBST(all_includes)
AC_SUBST(all_libraries)
---snip---

After updating your configure and Makefiles (e.g. by KDevelop menus
"Build/Autoconf and Automake" and "Build/Configure...") your Makefiles 
contain the symbol (better env.-var)
rtai_includes which can also be used inside your Makefile.am.
So instead using it inside configure.in:

all_includes="$all_includes $USER_INCLUDES $rtai_includes"

you can also use it in a certain Makefile.am with:
INCLUDES=$(all_includes) $(rtai_includes)

BTW: I didn't invent these scripts I have "stolen" and modified them 
from examples
like you find in kdevelop.m4 or acinclude.m4.in etc.

------------

Forth point:
including -g makes no sense IMHO, because you can use the --enable-debug 
switch of
configure. Without --enable-debug a "release" version of your code will 
be built,
which strips symbols to reduce size.

With KDevelop this will be done by using the dialog-box of the project 
options (again
limited to the KDevelop session)

Other flags like -f-switches can be included in Makefile.am:
AM_CFLAGS=-fno-strength-reduce

take care: here I'm using AM_CFLAGS instead of AM_CPPFLAGS...
you can see the difference by inspecting a created Makefile.
AM_CPPFLAGS is used only for compiling (so defines and includes are well 
placed)
while AM_CFLAGS is used for compiling and linking.

Knowing this makes clear that -MD should be inserted to AM_CPPFLAGS or
CPPFLAGS because this is a preprocessor option.
[NB: To be honest I don't know exactly if -MD would be also used for the
linkage (I don't think so), but if it would be used also for the linker
it should be placed in AM_CFLAGS or CFLAGS instead (at least my
gcc doesn't complain about it in the linkage pass).]

Known flags for overriding certain situations are:
AM_CPPFLAGS:
    C/C++ preprocessor flags - only for the Makefile.am 
(project-subdirectory)
CPPFLAGS:
    C/C++ preprocessor flags - project-global
    for usage inside configure.in(.in)
    this flag can be overridden by KDevelop or by a certain commandline
    action (e. g. make CPPFLAGS=-DZDEBUG)
AM_CFLAGS:
    C compiler switches/flags - only for the Makefile.am 
(project-subdirectory)
    Flags specified in here will be also passed to the linker
    (only available for C targets)
CFLAGS:
    C compiler switches/flags - project-global
    for usage inside configure.in(.in)
    this flag can be overridden by KDevelop or by a certain commandline
    action (e. g. make CFLAGS="-funsigned-bitfields -fstrength-reduce")
    (only available if project has C targets)
AM_CXXFLAGS:
    C++ compiler switches - only for the Makefile.am (project-subdirectory)
    Flags/switches specified in here will be also passed to the linker
    (only available for C++ targets)
CXXFLAGS:
    C++ compiler switches/flags - project-global
    for usage inside configure.in(.in)
    this flag can be overridden by KDevelop or by a certain commandline
    action (e. g. make CXXFLAGS="-fsigned-char")
    (only available if project has C++ targets)

special flag:
KDE_CXXFLAGS:
    suffixed C++ compiler switches/flags - project-global
    will be handled only if the "am_edit" script is present and will be
    called for example by "make -f Makefile.(cvs|dist)"
    (i.e. "KDevelop/Build/Automake and Autoconf")

    After making -fno-exceptions a default switch (to strip some stuff
    inside the binary, if no exception handling is used). You need
    also the possibility to switch it on again if a project would use it.

    Using AM_CXXFLAGS for it wouldn't work, because looking at a created
    Makefile you will see sth. like:
    $(CXX) ... $(AM_CXXFLAGS) $(CXXFLAGS) ....
    which results:
    gpp .... -fexceptions ... -fno-exceptions
    (again no-exceptions active)

    so KDE_CXXFLAGS were included to have the possibility to handle this
    ordering problem:
    $(CXX) ... $(AM_CXXFLAGS) $(CXXFLAGS) $(KDE_CXXFLAGS)....
    gpp ....   .....  .. ... -fno-exceptions -fexceptions
    (now exceptions active)

N.B: this examples are done for C/C++ terminal projects. If you want to 
apply this for projects with admin/ directory you may not modify 
configure.in, but configure.in.in.

Puhhh... now I've finished. Hoping some stuff now is clearer then before
and I haven't overloaded the mailing system.

Ciao

Walter

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