From kdevelop Sat Mar 17 12:24:12 2001 From: Walter.Tasin () t-online ! de (W ! Tasin) Date: Sat, 17 Mar 2001 12:24:12 +0000 To: kdevelop Subject: Re: how to turn off -fno-exceptions in kdevelop X-MARC-Message: https://marc.info/?l=kdevelop&m=98483208129664 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@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----------: - to unsubscribe from this list send an email to kdevelop-request@kdevelop.org with the following body: unsubscribe »your-email-address«