Hi and sorry to bother you again.
I haven't received any response so
I was wondering if there is still
interest in doing this.
On Tue, 28 Mar 2023, 17:43 Costas Argyris, wrote:
> 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 think this is a great idea, despite the fact that I expect most
> build environments to actually have a resource compiler (either
> windres or the msvc one) and therefore build with UTF-8.
>
> It certainly doesn't hurt to have this information output by Make
> itself - I can only see this being useful, even if the answer is
> UTF-8 most of the time.
>
> One comment about having it as part of --version is that it probably
> won't be easy to parse the used encoding out of the --version
> output, say, if a script wants to query for the encoding and pass a
> UTF-8 Makefile conditional on Make actually supporting UTF-8.
>
> Whether we want to care for this scenario or not is a different
> question though.
>
> If we decide to do this, it should simply be a call to the Windows
> GetACP() function - it will return 65001 if Make has been built
> with the UTF-8 manifest, or the identifier of the legacy system
> encoding otherwise.
>
> Actually, it will return 65001 (the UTF-8 identifier) in a couple other
> scenarios, even if Make hadn't been built with the manifest:
>
> 1) The user embedded the manifest manually using mt.exe
> This is officially documented and can very well happen.
> 2) The user has switched Windows to use UTF-8 as the
> active code page globally, for the entire OS.This is possible
> to do with a checkbox that is marked as "beta" by MS.
>
> So having Make return the output of GetACP would be useful
> because it would capture all these scenarios, including it
> having been built with the manifest of course.
>
> This is an example from ninja doing the same thing:
>
> https://github.com/ninja-build/ninja/pull/1918
>
> They did it by adding a new flag, so not part of --version.I like
> putting it in --version better because this does sound like the type
> of information one would expect to see there, the only problem
> being that it may not be easy to parse, unless we add it in a standard
> easy-to-parse format, like in a line of its own as:
>
> <--version output>
> ...
> Encoding: 65001
> or
> Encoding: 1252
> ...
>
> But it isn't "full UTF-8", as we have established during the
> discussions. MS-Windows is not yet ready for that, even in its latest
> versions.
>
> Yes, well, I guess what I really meant was "to the extent that Make
> itself can affect things".We can't do anything about Windows
> limitations anyway.I think there should be no problems at all
> if Make is linked against UCRT, and I hope that we won't hit many
> functions in MSVCRT that are not UTF-8-aware, but we couldn't
> do anything about these anyway.
>
> > That is, I am more inclined to make the configure version also error
> > out if windres was not found, than to make build_w32.bat optional.
>
> I'm of the opposite opinion.
>
> Sure, it shouldn't be hard to change build_w32.bat to make it optional.
> There is no precedent of such behavior in that batch file, as far as I can
> tell, so I'd have to come up with something like:
>
> if HAVE_WINDRES
> compile resource file
> else
> just skip resource file with no error, and don't try to link it
> end
>
> Then this is a non-issue: the error will not happen except in some
> situations we cannot imagine.
>
> That's what I think, but I could be wrong since I really can't imagine
> all the build environments people might be using, and, as I learned
> from this thread, there are quite a few ways to build so it's hard to
> anticipate for every possible scenario.
>
> Maybe it is best to just make compilation of the resource file optional,
> but, very importantly, with the addition of your suggestion about printing
> the encoding used in --version.That way, everyone will manage to
> build as they currently do with no surprises about this, and they will
> also be able to query Make any time for its encoding.
>
> I'd like to avoid annoying users with requests to install something
> they did well without previously. Some would consider this a
> regression.
>
> Makes sense, see above response.
>
> On Tue, 28 Mar 2023 at 12:22, Eli Zaretskii wrote:
>
>> > From: Costas Argyris
>> > Date: Mon, 27 Mar 2023 23:04:52 +0100
>> > Cc: bug-make@gnu.org
>> >
>> > > Should we fail here? Or should we build without UTF-8 support since
>> we
>> > > don't have a resource compiler? I think that's what the configure
>> > > version does, right?
>> >
>> > You are right, that was an inconsistency on my part, sorry about that.
>> > It's true that the configure version is optional on this, whereas
>> > build_w32.bat errors out.
>> >
>> > I think the answer depends on what is going to be the policy regarding
>> > Make on Windows and UTF-8.If we want to claim
