Thank you both for your input.
I think you should move the assignment of UTF8OBJ out of the if-
statement here, and only put the update of make_LDADD into the if-
statement. That should be sufficient to have make ignore that target,
if there's no WINDRES available.
I'll make that change, thanks.
> From: Costas Argyris
> Date: Tue, 11 Apr 2023 12:01:20 +0100
> Cc: Eli Zaretskii , bug-make@gnu.org
>
> > Being able to know whether UTF-8 is supported or not is a valid
> > concern. How about adding this information to what "make --version"
> > shows?
>
> I agreed with that suggestion and pr
I don't think this is needed: if GetACP returns the UTF-8 codepage, it
must be that UTF-8 is supported. I'm not aware of any way of
affecting GetACP other than by a manifest such as this one (or perhaps
making UTF-8 a system-wide default, which is fine by us).
This is the scenario I am concerned
> From: Costas Argyris
> Date: Tue, 11 Apr 2023 14:42:30 +0100
> Cc: bug-make@gnu.org, Paul Smith
>
>> I don't think this is needed: if GetACP returns the UTF-8 codepage, it
>> must be that UTF-8 is supported. I'm not aware of any way of
>> affecting GetACP other than by a manifest such as this
AFAIK, GetACP can never return UTF-8, except if the program was
compiled with those resources.
In the scenario I am describing, Make was compiled with the resource,
so GetACP should return UTF-8 on the one hand.On the other hand
though, since Make is running in Windows version < 1903, it shoul
> From: Costas Argyris
> Date: Tue, 11 Apr 2023 14:50:53 +0100
> Cc: bug-make@gnu.org, psm...@gnu.org
>
> > AFAIK, GetACP can never return UTF-8, except if the program was
> > compiled with those resources.
>
> In the scenario I am describing, Make was compiled with the resource,
> so GetACP sho
