OnThu, Sep 2, 2021 at 3:42 AM Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > On Thu, Sep 02 2021, Ævar Arnfjörð Bjarmason wrote: > > 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? OK, I have to admit, this is mainly because gettext and msgfmt come from different packages in OpenBSD, and I keep forgetting to install the latter. It makes sense too, if you only care about a quick build and your binary won't use the message files (ex: a git part of a build container or a portable minimal package); you are correct I usually do NO_GETTEXT=1 as well in that case, which is why I didn't saw the tests breaking. > > I understand why you'd want NO_GETTEXT in that case, but what's the > > point of building with NO_GETTEXT= NO_MSGFMT=Y? I think they are conceptually different, one instructs the build system that we want to build international support in the binary, while the other only says "I have this tool and want the catalogs generated with it" > > 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? the gettext() calls fail cleanly if there are no catalogs to use, so I wouldn't agree it is broken and more importantly, will start using them if they are provided and the binary is pointed to them, they don't need to be freshly generated or even match the version of the binary they are queried from. > > 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. apologies, thanks for checking, that was sloppy of me. > Some further digging reveals that we've got in-tree git-gui/po/po2msg.sh > and gitk-git/po/po2msg.sh (copy/pasted, but slightly different) that > supports some subset of "msgfmt --tcl". > > I.e. those programs with NO_MSGFMT still end up with locale files they > can use, whereas in this patch we don't end up with anything at all... I have to admit I found odd we had those as I was expecting they should behave like git in this case and don't generate any mo files. FWIW Git for Windows seems to go to great extents to NOT include those in the release. Carlo
