Re: [PATCH v2 1/2] *: add modern gettext support

[Jan Beulich <jbeulich@suse.com>]

On 26.09.2023 16:44, Arsen Arsenović wrote:
> Hi,
> 
> Jan Beulich <jbeulich@suse.com> writes:
> 
>> May I please ask that a change like this come with a real description? The
>> ChangeLog entries certainly describe - purely mechanically - what is done
>> to the files, but to be honest I cannot really read out of the (large)
>> patch what the overall behavioral change is.
> 
> Hopefully, none.  Building without gettext in-tree or on the system
> should result in a working build with no localization, with gettext
> in-tree and on the system it should result in the usage of the system
> gettext, with gettext on the tree but _not_ on the system, it should
> result in a new (static) copy being built and linked into the tools,
> with working localization, and with no gettext in tree but in system
> (either in libc or in libintl) should result in a localized build using
> the system gettext facilities.
> 
> The behavior for the in-tree but also on the system case (e.g. building
> with gettext in-tree on a GNU system) can be overridden with
> --with-included-gettext (which is a configure flag for gettext-runtime,
> and was a configure flag for intl/ before that).
> 
> I've updated the commit message to add:
> 
>> This patch updates gettext.m4 and related .m4 files and adds
>> gettext-runtime as a gmp/mpfr/... style host library, allowing newer
>> libintl to be used.
>>
>> This patch /does not/ add build-time tools required for
>> internationalizing (msgfmt et al), instead, it just updates the
>> runtime library.  The result should be a distribution that acts
>> exactly the same when a copy of gettext is present, and disables
>> internationalization otherwise.
>>
>> There should be no changes in behavior when gettext is included
>> in-tree.  When gettext is not included in tree, nor available on the
>> system, the programs will be built without localization.
> 
> I hope this clarifies it.
> 
> Would you like to see anything else in the description?

This looks sufficient to me, thanks. I don't feel qualified though to
approve the binutils side of the change, sorry. I merely wanted to make
sure there won't be sudden (and unmentioned) regressions as to where
binutils can(not) be built.

Jan