[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Gettext macros (and a couple other ones)
From: |
Alessio Vanni |
Subject: |
Re: Gettext macros (and a couple other ones) |
Date: |
Sun, 29 Aug 2021 19:15:30 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
Christian Grothoff <grothoff@gnunet.org> writes:
> Good point, but that's a specific issue with that macro, which I agree
> should not use "_" but dgettext(). I've fixed this (and a few related)
> instance(s) in Git master just now.
Hello,
thanks for the fix.
Related to this issue: since those macros explicitly use `dgettext' I
thought I'd try to place the "gettext.h" header directly inside
"gnunet_common.h", so that `dgettext' is always defined, but I
discovered that "platform.h" contains this snippet:
#include <locale.h>
#ifndef FRAMEWORK_BUILD
#include "gettext.h"
/**
* GNU gettext support macro.
*/
#define _(String) dgettext (PACKAGE, String)
#define LIBEXTRACTOR_GETTEXT_DOMAIN "libextractor"
#else
#include "libintlemu.h"
#define _(String) dgettext ("org.gnunet.gnunet", String)
#define LIBEXTRACTOR_GETTEXT_DOMAIN "org.gnunet.libextractor"
#endif
It appears that FRAMEWORK_BUILD is never defined anywhere, even though
it's part of `gnunet_config.h.in'. Is it safe to remove it?
In case it can be removed, then "gettext.h" can be simply included by
"gnunet_common.h" too since multiple inclusions are guarded by the
preprocessor, meaning that GNUnet will keep using the `_' macro defined
by "platform.h" while other applications don't have to explicitly add
"#include <gnunet/gettext.h>" before including the "gnunet_util_lib.h"
header.
If it can't be removed, things are going to be a bit inconsistent, since
"gettext.h" would be included even when it shouldn't. The #ifndef check
can't be reliably performed inside "gnunet_common.h" for the same
reasons why GNUNET_AGPL_URL can give an incorrect value, i.e. it's a
public header which can get values from anything included before it,
like a "config.h" generated by Autoconf and thus FRAMEWORK_BUILD might
be defined for unrelated reasons, making things break unexpectedly.
Thanks,
A.V.