GNOME Bugzilla – Bug 357830
broken --enable-api-default-signal-handlers option
Last modified: 2006-09-28 15:58:08 UTC
From Matt Hoosier on the gtkmm mailing list: The M4 macro (from scripts/reduced.m4) which controls whether default signal handlers will be exposed as virtual functions seems to have a typo: AC_DEFUN([GLIBMM_ARG_ENABLE_API_DEFAULT_SIGNAL_HANDLERS], [ AC_ARG_ENABLE([api-exceptions], [ --enable-api-default-signal-handlers Build default signal handlers API. [[default=yes]]], [glibmm_enable_api_default_signal_handlers="$enableval"], [glibmm_enable_api_default_signal_handlers='yes']) if test "x$glibmm_enable_api_default_signal_handlers" = "xyes"; then { AC_DEFINE([GLIBMM_DEFAULT_SIGNAL_HANDLERS_ENABLED],[1], [Defined when the --enable-api-default-signal-handlers configure argument was given]) } fi ]) Note that the AC_ARG_ENABLE clause uses "api-exceptions" as the salient bit, when I guess it should probably be "api-default-signal-handlers". This has the effect that $glibmm_enable_api_default_signal_handlers never takes on the "yes" value, and the virtual functions are never enabled. This seems to affect HEAD, 2-10, and 2-12 branches
I'm not sure how, but the configure help does list the correct option: " --enable-use-deprecations warn about deprecated usages [default=no] --enable-deprecated-api Include (build) deprecated API in the libraries. [default=yes] --enable-api-exceptions Build exceptions API. [default=yes] --enable-api-properties Build properties API. [default=yes] --enable-api-vfuncs Build vfuncs API. [default=yes] --enable-api-default-signal-handlers Build default signal handlers API. [default=yes] " and glibmmconfig.h does define the macro, by default: " #define GLIBMM_PROPERTIES_ENABLED 1 #define GLIBMM_VFUNCS_ENABLED 1 #define GLIBMM_EXCEPTIONS_ENABLED 1 #define GLIBMM_DEFAULT_SIGNAL_HANDLERS_ENABLED 1 #endif " But I'll fix it all the same.
Comitted to HEAD, glibmm-2-12, glibmm-2-10, and glibmm-2-8 branches. I don't think new tarball releases are necessary, but tell me if I'm wrong.
You mentioned that the macro is defined by default. One thing you might want to check is whether it's possible to _disable_ the default signal handlers. If not, it might be worth re-rolling releases. Or maybe you know the answer to that already...
Yes, it really seems to work as expected, as if that macro parameter is ignored. By the way, when building without disabled examples, you know when you've disabled default-signal-handlers because the examples won't build. (Ifdefing for this would just obscure the examples a bit too much.)
I'm not totally convinced that the switches work as-is. For instance, the following combination of options: --enable-deprecated-api=no \ --enable-api-exceptions=no \ --enable-api-vfuncs=no \ --enable-api-properties=no resulted in a glibmmconfig.h with the following: /* #undef GLIBMM_PROPERTIES_ENABLED */ /* #undef GLIBMM_VFUNCS_ENABLED */ /* #undef GLIBMM_EXCEPTIONS_ENABLED */ /* #undef GLIBMM_DEFAULT_SIGNAL_HANDLERS_ENABLED */ Perhaps the real effect of that typo was to make "glibmm_enable_api_default_signal_handlers" take on whatever value was implied by the --enable-api-exceptions switch.
(In reply to comment #1) > I'm not sure how, but the configure help does list the correct option: > " > --enable-use-deprecations > warn about deprecated usages [default=no] > --enable-deprecated-api Include (build) deprecated API in the libraries. > [default=yes] > --enable-api-exceptions Build exceptions API. > [default=yes] > --enable-api-properties Build properties API. > [default=yes] > --enable-api-vfuncs Build vfuncs API. > [default=yes] > --enable-api-default-signal-handlers Build default signal handlers API. > [default=yes] > " > > and glibmmconfig.h does define the macro, by default: > " > #define GLIBMM_PROPERTIES_ENABLED 1 > #define GLIBMM_VFUNCS_ENABLED 1 > #define GLIBMM_EXCEPTIONS_ENABLED 1 > #define GLIBMM_DEFAULT_SIGNAL_HANDLERS_ENABLED 1 > #endif > " > > But I'll fix it all the same. > I think that the help text is misleading; the M4 macro definition makes one separately indicate what string (here, "--enable-api-default-signal-handlers" completely spelled out) goes into that message. This can vary from the actual switch being declared. See my comment later down on this bug for a counterexample.
Still, the defaults are OK, and I guess the combination that you need is OK. Is it OK to wait a few more days before rolling more tarballs, in case any other problems are found?
Ah, I guess you want to disable exceptions without disabling default-signal-handlers, and I guess that doesnt't work. I'll do new releases.
Should we also automatically disable building examples if we disable any of these things? That way the build won't fail due to examples not building...
No, I want people to only use these options if they know what they are doing. And I quite like having the build break if it's used by accident. I'm more likely to ifdef the examples one day to support a build with this option.
New releases of glibmm 2.8, 2.10, 2.12, and 2.13 are out. Please reopen this bug if there's still a problem.