From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: "Carlo Marcelo Arenas Belón" <carenas@gmail.com>
Cc: git@vger.kernel.org, Johannes.Schindelin@gmx.de
Subject: Re: [PATCH] makefile: teach git about NO_MSGFMT (as supported in GUI and gitk)
Date: Thu, 02 Sep 2021 12:27:56 +0200 [thread overview]
Message-ID: <87ilzjuv2t.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <20210902085438.54121-1-carenas@gmail.com>
On Thu, Sep 02 2021, Carlo Marcelo Arenas Belón wrote:
> NO_MSGFMT can be used to indicate there is no msgfmt available, so
> make git recognize that and avoid failing to build while trying to
> generate i18n files.
Why would we want to avoid failing the build if we don't have msgfmt?
I understand why you'd want NO_GETTEXT in that case, but what's the
point of building with NO_GETTEXT= NO_MSGFMT=Y?
If we can't build the *.mo files we'll have a completely broken
installation that can't do anything useful with gettext, so why not just
build without gettext at that point?
When this patch is applied a lot of things related to gettext in our
tests fail if you build with NO_GETTEXT= NO_MSGFMT=Y, because those
things are assuming that if NO_GETTEXT isn't defined we'll have the *.mo
files, po/build etc.
> while at it, refactor the change introduced in 4348824059
> (artifacts-tar: respect NO_GETTEXT, 2021-07-04) with something as
> functional but shorter.
>
> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
> ---
> Makefile | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 9573190f1d..9f09a75801 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -86,6 +86,8 @@ all::
> # Define LIBC_CONTAINS_LIBINTL if your gettext implementation doesn't
> # need -lintl when linking.
> #
> +# Define NO_MSGFMT if you don't have msgfmt
> +#
> # Define NO_MSGFMT_EXTENDED_OPTIONS if your implementation of msgfmt
> # doesn't support GNU extensions like --check and --statistics
> #
> @@ -2691,10 +2693,8 @@ po/git.pot: $(GENERATED_H) FORCE
> .PHONY: pot
> pot: po/git.pot
>
> -ifdef NO_GETTEXT
> -POFILES :=
> -MOFILES :=
> -else
> +ifndef NO_MSGFMT
> +ifndef NO_GETTEXT
> POFILES := $(wildcard po/*.po)
> MOFILES := $(patsubst po/%.po,po/build/locale/%/LC_MESSAGES/git.mo,$(POFILES))
>
> @@ -2703,6 +2703,7 @@ endif
>
> po/build/locale/%/LC_MESSAGES/git.mo: po/%.po
> $(QUIET_MSGFMT)mkdir -p $(dir $@) && $(MSGFMT) -o $@ $<
> +endif
>
> LIB_PERL := $(wildcard perl/Git.pm perl/Git/*.pm perl/Git/*/*.pm perl/Git/*/*/*.pm)
> LIB_PERL_GEN := $(patsubst perl/%.pm,perl/build/lib/%.pm,$(LIB_PERL))
next prev parent reply other threads:[~2021-09-02 10:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-02 8:54 [PATCH] makefile: teach git about NO_MSGFMT (as supported in GUI and gitk) Carlo Marcelo Arenas Belón
2021-09-02 10:27 ` Ævar Arnfjörð Bjarmason [this message]
2021-09-02 10:38 ` Ævar Arnfjörð Bjarmason
2021-09-03 2:32 ` Carlo Arenas
2021-09-02 15:32 ` Johannes Schindelin
2021-09-03 1:54 ` Carlo Arenas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ilzjuv2t.fsf@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=carenas@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.